System and method for implementing a global master patient index

ABSTRACT

Separate computer systems may participate in a Health Data Network (HDN) such that the computer systems are linked so as to share various types of healthcare-related information. The shared information may include patient record information. The integration of the patient record information is accomplished by maintaining a Global Master Patient Index (GMPI). Such a GMPI may integrate patient record information used by multiple healthcare organizations, facilities, or businesses. Such a GMPI may also integrate patient record information for a single business having multiple sites or computer systems, e.g., a large hospital. The GMPI preferably provides for performing functions such as locating patient records, locating duplicate records for a selected patient, printing a selected patient record with all its duplicate patient records, reconciling potential duplicate patient records found while searching and retrieving a patient&#39;s record final reconciliation (certification) of suspected duplicate patients records, maintaining a persistent relationship between patient records in the GMPI, and maintaining a reconciliation audit trail.

PRIORITY CLAIM

[0001] This application claims benefit of priority of U.S. provisionalapplication Serial No. 60/167,532 titled “System and Method Enabling aDistributed Object-to-Relational Application Framework”, filed Dec. 1,1999, whose inventors were Robert Yeager, Kurt Schurenberg, and RobinJohnson.

FIELD OF THE INVENTION

[0002] The present invention relates to the field of healthcareinformation systems, and more particularly to a system and method forimplementing a Global Master Patient Index (GMPI) for managing patientrecords used by multiple healthcare businesses, sites, or facilities.

DESCRIPTION OF THE RELATED ART

[0003] The healthcare industry has historically suffered frominformation flow and workflow fragmentation. In the past, informationwas typically exchanged among various parties involved in healthcare,such as physicians, hospitals, insurers, laboratories, employers, andothers, using paper-based methods. As is well known in the art, suchmethods are inherently labor-intensive, inefficient, and error prone.Thus, efforts have been undertaken to improve the healthcare industrythrough the use of electronic information networks integratinghealthcare participants.

[0004] There are many difficulties to overcome in implementing such anelectronic information network, also referred to herein as a Health DataNetwork (HDN). One primary difficulty involved is how to integrate andensure the integrity of data maintained and used by the varioushealthcare parties. In particular, the integration of patient recordsthat are created and used by the parties has historically been adifficult and important problem.

[0005] Duplicate patient records create problems for hospitals,physician practices, and other parties involved in healthcare. Failureto find preexisting records creates duplicate files for the sameindividual. Duplicate records splinter clinical information and hinderaccess. Impaired access to complete patient information hinders aclinician's ability to quickly and accurately treat a patient. Duplicaterecords impact billing processes and decision support foradministration.

[0006] Causes of incorrect and improper patient entries vary. Forexample, policies and procedures may be inadequate to support thoroughresearch of patient identities. Lack of training, lack of staff, poormotivation and skill sets all may degrade the quality of data entry andlookup. Variability of patient name spelling, use of nicknames,marriage, divorce, adoption, prefixes, and abbreviations of names allcontribute to the problem. Human error is a common factor. Also, apatient's mental status at the time of presentation may precludeobtaining accurate information. All of these factors may impact eitherthe quality of search or the quality of the database.

[0007] In the healthcare industry, the index of patients past andcurrent is commonly known by several names, including:

[0008] Master Patient Index (MPI)

[0009] Master Person Index (MPI)

[0010] Master Customer Index (MCI)

[0011] Enterprise Master Patient/Person Index, (EMPI)

[0012] Global Master Patient/Person Index (GMPI)

[0013] The first three names commonly imply one host system. Complexhealth systems employ the usage of the terms “enterprise” or “global”.The term Global Master Patient Index or GMPI is used herein to refer toan index used by multiple sites, facilities, businesses, or otherorganizations.

[0014] Health Data Networks (HDNs) exacerbate the problem of duplicaterecord creation through consolidation of databases. The HDN environmentmay link hospital facilities, physician practices, laboratories, healthplans, and other organizations together in the provision of patientcare. Multiple registration locations, varied data entry processes, anddisparate collection systems characterize this network environment. Manycategories of personnel may use the GMPI information, includingphysicians, nurses, health information management staff,registration/admitting office staff, and administrative support staff,among others.

[0015] A GMPI helps to streamline vital clinical and payer information.For example, uses of the GMPI may include:

[0016] Patient Registration

[0017] Claims Payment

[0018] Release of Information (Subpoenas, school immunizationverification, etc.)

[0019] Administrative Review Processes (Peer review, Risk Management,Infection Control, Utilization Management)

[0020] Loose Report Processing

[0021] Physician Referrals

[0022] Routing visitors, flowers, patient mail

[0023] Thus, it would be desirable to provide a system and method forimplementing and successfully maintaining the integrity of a GlobalMaster Patient Index for a Health Data Network.

SUMMARY OF THE INVENTION

[0024] According to one embodiment of the invention, separate computersystems may participate in a Health Data Network (HDN). That is, thecomputer systems may be linked so as to share various types ofhealthcare-related information. The shared information may includepatient record information. The integration of the patient recordinformation is accomplished by maintaining a Global Master Patient Index(GMPI), such as described herein. Such a GMPI may integrate patientrecord information used by multiple healthcare organizations,facilities, or businesses. Such a GMPI may also integrate patient recordinformation for a single business having multiple sites or computersystems, e.g., a large hospital.

[0025] The GMPI preferably provides for performing functions such aslocating patient records, locating duplicate records for a selectedpatient, printing a selected patient record with all its duplicatepatient records, reconciling potential duplicate patient records foundwhile searching and retrieving a patient's record final reconciliation(certification) of suspected duplicate patients records, maintaining apersistent relationship between patient records in the GMPI, andmaintaining a reconciliation audit trail.

[0026] As an example of one function of the GMPI, suppose that a patientvisits Physician's Office A for the first time, and this patient haspreviously visited Physician's Office B, wherein Physician's Office A(Office A) and Physician's Office B (Office B) are both participants(referred to as HDN businesses) in a Health Data Network linked by aGMPI. Thus, the patient may have a patient record that was previouslycreated by a person at Office B, which may be stored on a computersystem at Office B or on a server computer to which computers of OfficeA and Office B are linked. Upon registration at Office A, a clerk mayperform a search for previously existing records for the patient, e.g.,using a local computer at Office A. As described below, the Office Acomputer is preferably enabled to retrieve the existing record for thepatient that was created by the person at Office B, e.g., either byinterfacing directly with the Office B computer or with the servercomputer described above.

[0027] In one embodiment, the computer systems associated with thevarious HDN Businesses may interface with a middleware server thatfacilitates the retrieval and update of patient records. For example, inthe patient registration situation referred to above, in response to theclerk's request to lookup a record for the patient, an applicationrunning on a computer system at Physician's Office A may request themiddleware server to retrieve any existing records for the patient,e.g., by specifying one or more identifiers associated with the patient.such as the patient's name, SSN, etc.

[0028] The middleware server may then retrieve the record, e.g., from adatabase associated with Physician's Office B or from another database.In various embodiments, the middleware server may retrieve the patientrecord in any of various ways. For example, in one embodiment themiddleware server may be operable to maintain or interface with an indexcross-referencing patient identifier information with the location ofcorresponding patient records, i.e., the databases or sites at which therecords may be found. In another embodiment, the middleware server mayquery the various sites of the Health Data Network to locate records forthe specified patient.

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] A better understanding of the present invention can be obtainedwhen the following detailed description of the preferred embodiment isconsidered in conjunction with the following drawings, in which:

[0030]FIG. 1 is a block diagram illustrating the use of a Global MasterPatient Index, or GMPI, as enabled by one embodiment of the presentinvention;

[0031]FIG. 2 illustrates one embodiment of a system employing amiddleware server to facilitate the integration of patient recordinformation;

[0032]FIG. 3 is a diagram illustrating an example of various types ofGMPI links among a set of patient records;

[0033]FIG. 4 is a state diagram illustrating various state changes thata GMPI link may undergo, according to one embodiment;

[0034]FIG. 5 is a flowchart diagram illustrating one embodiment of amethod for automatically creating an unconfirmed link between twopatient records;

[0035]FIG. 6 is a flowchart diagram illustrating one embodiment of amethod for looking up patient records in the GMPI, in response to userinput;

[0036]FIG. 7 is a flowchart diagram illustrating one embodiment of amethod for confirming a link from a record A to a record B, wherein anon-directional link, such as an unconfirmed or denigrated link, existsbetween A and B;

[0037]FIG. 8 is a flowchart diagram illustrating one embodiment of amethod for certifying a link from a record A to a record B, whereinrecord A is a trailer record with a confirmed link to a leader record B;

[0038]FIG. 9 is a flowchart diagram illustrating one embodiment of amethod for creating a denigrated link between a patient record A and apatient record B, wherein there is an existing unconfirmed link betweenA and B;

[0039]FIG. 10 is a flowchart diagram illustrating one embodiment of amethod for denigrating a link between a record A and a record B, whereinrecord A is a trailer record with a directional link to leader record B;and

[0040] FIGS. 11-107 describe an exemplary laboratory applicationoperable to use a GMPI to integrate patient information acrosshealthcare businesses.

[0041] While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and are herein described in detail. It should beunderstood, however, that the drawings and detailed description theretoare not intended to limit the invention to the particular formdisclosed, but on the contrary, the intention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Incorporation byReference

[0042] The following reference is hereby incorporated by reference inits entirety as though fully and completely set forth herein:

[0043] U.S. Pat. No. 5,724,575 titled “Method and System forObject-Based Relational Distributed Databases”, issued Mar. 3, 1998,whose inventors were Michael K. Hoover, Barrick H. Miller, KurtSchurenberg, and Richard A. Daigle.

[0044] U.S. provisional application Serial No. 60/167,532 titled “Systemand Method Enabling a Distributed Object-to-Relational ApplicationFramework”, filed Dec. 1, 1999, whose inventors were Robert Yeager, KurtSchurenberg, and Robin Johnson.

[0045]FIG. 1

[0046]FIG. 1 is a block diagram illustrating the use of a Global MasterPatient Index, or GMPI, as enabled by one embodiment of the presentinvention. Several exemplary sites 60 are shown. Each site 60 may beassociated with a health care organization, facility, or business, suchas a physician's office, laboratory, health plan, hospital, etc. Theindividual sites 60 may be operable to share various types ofinformation with each other, including patient record information, suchas patient contact and billing, information, patient medical history,etc. In other words, the sites 60 may be associated with a Health DataNetwork (HDN), and the organization or business associated with eachsite may be referred to as an HDN Business. It is noted that the sites60 shown in FIG. 1 represent typical types of businesses found in atypical Health Data Network, and any of various other organizations maybe present in other embodiments of a Health Data Network. Also, anynumber of organizations or businesses may be connected to the HDN.

[0047] As shown, each site 60 may utilize a computer system 62 thatinterfaces to one or more databases 64. Among other types ofinformation, a database 64 may store patient record information. The useof patient record information may differ for the various sites. Forexample, Physician's Office A (site 60B) may primarily use the patientrecords to view and update clinical information regardingpatients'medical history, while the Health Plan (site 60D) may primarilyuse the patient records to manage insurance information for therespective patients.

[0048] According to the preferred embodiment of the present invention,patient record information used by the various sites 60 may beintegrated across the Health Data Network, as indicated in FIG. 1 by theGlobal Master Patient Index (GMPI) interconnecting the various sites. Asdescribed above, a GMPI may help to improve patient care and increasethe efficiency of healthcare businesses by helping to detect theexistence of and avoid the creation of duplicate patient records.

[0049] In various embodiments, the system and methods described hereinmay be used to enable a GMPI for a set of distinct businesses that shareinformation, such as illustrated in FIG. 1. The system and methods mayalso be employed by a single healthcare business. For example, ahealthcare business such as a hospital may have a plurality ofdepartments which utilize the GMPI to integrate patient recordinformation for the various departments. Also, a healthcare business mayhave multiple physically separated sites that may employ the system andmethods described herein to share patient record information among themultiple sites.

[0050] As an example of one function of the GMPI, suppose that a patientvisits Physician's Office A (site 60B) for the first time, and thispatient has previously visited Physician's Office B (site 60E). Thus,the patient may have a patient record that was previously created by aperson at Physician's Office B, e.g., by using an application running oncomputer system 62E. Upon registration at Physician's Office A, a clerkmay perform a search for previously existing records for the patient.For example, the clerk may utilize an application running on computersystem 62B to perform this search. As described below, the applicationis preferably enabled to retrieve the existing record for the patientthat was created by the person at Physician's Office B.

[0051] In various embodiments, the patient record previously created atPhysician's Office B may be stored at and retrieved from variouslocations. For example, this record may be stored in the database 64E atsite 60E, and the application running on computer system 62B may beoperable to retrieve the record from this database. As another example,the record may be stored in a database not specifically associated withPhysician's Office B. For example, when the person at Physician's OfficeB creates the record, the record may be stored in a central databasethat stores patient record information for the various HDN Businesses.

[0052] In one embodiment, the computer systems associated with thevarious HDN Businesses may interface with a middleware server thatfacilitates the retrieval and update of patient records. For example, inthe patient registration situation referred to above, in response to theclerk's request to lookup a record for the patient, an applicationrunning on computer system 62B at Physician's Office A may request themiddleware server to retrieve any existing records for the patient,e.g., by specifying one or more identifiers associated with the patient.such as the patient's name, SSN, etc.

[0053] The middleware server may then retrieve the record, e.g., fromthe database 64E associated with Physician's Office B or from anotherdatabase. In various embodiments, the middleware server may retrieve thepatient record in any of various ways. For example, in one embodimentthe middleware server may be operable to maintain or interface with anindex cross-referencing patient identifier information with the locationof corresponding patient records, i.e., the databases or sites at whichthe records may be found. In another embodiment, the middleware servermay query the various sites of the Health Data Network to locate recordsfor the specified patient.

[0054]FIG. 2

[0055]FIG. 2 illustrates one embodiment of a system employing amiddleware server to facilitate the integration of patient recordinformation. It is noted, however, that any of various systems orarchitectures may be used to retrieve remote patient records and tomaintain the Global Master Patient Index described with reference toFIG. 1.

[0056]FIG. 2 illustrates a client application 100 that interfaces with aClient Object Server 110. For example, referring again to the patientregistration example given above, the client application 100 may be theapplication that the clerk at Physician's Office A uses to lookuprecords for the patient. The client application 100 may also be any ofvarious other types of applications running on any of the other sites 60shown in FIG. 1. For example, the client application 100 may be aregistration application running on computer system 62A at the hospitalof site 60A or may be an application associated with managing insuranceclaims running on computer system 62D at the health plan of site 60D.

[0057] The Client Object Server 110 with which the client application100 interfaces may perform the functions of the middleware serverdescribed above. The Client Object Server 110 preferably provides asingle standard interface for all of the various client applicationsrunning on computer systems 62. The Client Object Server 110 preferablyprovides an API related to the GMPI which client applications 100 mayuse to search for patient records, put patient records, delete patientrecords, etc.

[0058]FIG. 2 illustrates a client application 100 that interfaces with aclient object server (COS) 110. The client application may be any ofvarious types of computer processes, such as an application that a userinteracts with, an application for performing bulk data loading, acommunication process associated with another computer system, etc.

[0059] The FIG. 2 framework enables a client application to interactwith distributed relational databases using a software object model. Forexample, an application dealing with customer invoices may request a“customer invoice object” from the client object server 110, in order towork with the customer invoice in terms of a software object, such as aC++ or Java object-oriented programming style object. The data for thecustomer invoice object may be stored in separate tables within adatabase, or may even be stored in separate databases. The client objectserver 110 is responsible for managing the retrieval and storage ofobject data from/to the appropriate locations. In other words, the FIG.2 framework enables client application logic to be written independentlyof the data tier(s), and enables data tier(s) to change withoutrequiring client applications to be re-written.

[0060] Modern distributed applications often utilize data stored incomplex relational models. Enabling client applications to work with thedata without requiring knowledge of the complex data model may greatlysimplify application programming. Also, data integrity may be increased.For example, when data is added to one table, the data model may specifythat a second table should also be updated to reflect the change.However, client application programmers may not know of the need toupdate the second table, or may forget to do so, resulting in dataintegrity.

[0061]FIG. 2 also illustrates an object dictionary 120. The clientobject server 110 interfaces with the object dictionary 120 todynamically determine the data location(s), layout, andretrieval/storage methods. The object dictionary comprises metadatainformation regarding the data location(s), layout, andretrieval/storage methods for each object that client applications mayrequest from the client object server. For example, the objectdictionary may comprise information regarding a customer invoice object,as in the example above. The types of objects that may be defined andmanaged by the client object server is of course unlimited, and maydepend on the purpose of a particular system or application. Forexample, a healthcare system may define objects representing patients,healthcare providers, etc. The object definitions may be dynamicallychanged by changing the object dictionary metadata information.

[0062] For more information on the interaction of the client objectserver with the object dictionary and for information on objectlifecycle, please refer to the documentation incorporated by reference.

[0063] In one embodiment, information is passed between the clientapplication and the client object server via CORBA sequences, e.g., asstructured name/value pairs enabling the construction of an “object” onthe client-side. Advantageously, this enables client applications toutilize object-oriented style programming without requiring trueindividual objects, e.g. CORBA objects, to be instantiated and passed toeach client application, which could lead to scalability problems for asystem with a large number of client applications that communicate withthe client object server.

[0064] As shown in FIG. 2, the client object server 110 may interfacewith multiple service provider modules 130. Each service provider module130 may provide a computing service or interact with another computersystem. For example, FIG. 2 illustrates a service provider 130B thatinteracts with an object broker data server 140, such as the objectbroker data server described in the above-incorporated documentation. Asother examples, a service provider may interact with a file system, aservice provider may provide TCP/IP communication abilities, etc.Service providers may also be specific to a particular system orapplication. For example, an “eligibility” service provider may enablehealthcare applications to determine the healthcare insuranceeligibility information for a particular patient.

[0065] Thus, service providers 130 may add multi-tier aspects to theFIG. 2 framework. The client object server 110, together with the objectdictionary 120, may enable client applications to utilize the respectiveservice resources in an object-oriented style, without requiring clientapplications to possess knowledge of the service implementations. Forexample, a healthcare application may connect to an external healthcarepayer system via an eligibility service provider and query the insuranceeligibility status for an individual, using object-oriented methods asdescribed above.

[0066] Each service provider may communicate with the client objectserver via CORBA sequences, similarly as described above, and maycommunicate with its respective resource in any way appropriate. Forexample, a service provider may interface with a database resource usinga database communication protocol.

[0067] Service providers are preferably implemented so that new serviceproviders may easily be incorporated into the framework. In oneembodiment, the client object server communicates with each serviceprovider via a common CORBA interface. Thus, a new service provider maybe added by simply implementing this interface, as appropriate for therespective resource.

Terminology

[0068] The following terms are used herein to describe one embodiment ofa Global Master Patient Index.

[0069] Unconfirmed link—A link between two records indicating that therecords are suspected to correspond to the same person, i.e., indicatingthat the records are suspected as being duplicates. An unconfirmed linkmay be automatically created by the system. For example, the existenceof an unconfirmed link may indicate that the system has detected twopatient records where elements of the records, such as Real WorldPrimary Keys (first name, last name, social security number, date ofbirth, etc.), have enough similarities for the system to flag therecords as possible duplicates. In one embodiment, unconfirmed links arepairwise, i.e., link two patient records. A given patient record mayparticipate in more than one link. An unconfirmed link isnon-directional. In other words, neither associated record is thought tobe more correct or up-to-date than the other.

[0070] Confirmation—A first level of sanctioning a link between a pairof records. For example, confirmation may change an unconfirmed link toa confirmed link or a denigrated link. In the healthcare workflow,confirmation may occur at the point of entry into the system.Confirmation may typically be performed by a clerk or other user who hasdirect access to the patient. Confirmation may either affirm anassociation of a pair of records as true (Confirmed Link) or it mayreject the association (Denigrated Link).

[0071] Confirmed link—A link where a user has confirmed an unconfirmedlink detected by the system, or has detected an association betweenpatient records without intervention of the system and has created alink between the records. In the preferred embodiment, a confirmed linkis directional, i.e., one record is specified as the most correct,proper, or current record, and the other is thus considered a “trailer”record. The trailer record points or links to the most correct record,which is referred to as a “leader” record.

[0072] Certification—A second level of sanctioning a link between a pairof records. For example, certification may change a confirmed link to acertified link or a denigrated link. In the healthcare workflow,certification may be performed by a user responsible for reviewing linksbetween records and supervising and maintaining the integrity of theGMPI. For example, certification may be a privileged operation whichonly certain users may perform. These users are referred to herein asGMPI administrators.

[0073] Certified link—A link where a user has certified two records asbeing duplicates. In the preferred embodiment, a confirmed link isdirectional, i.e., one record is specified as the most correct, proper,or current record, and the other is thus considered a trailer record. Inone embodiment, when certifying a confirmed link, the user may reversethe direction of the confirmed link if it is determined that the trailerrecord should actually be the leader record.

[0074] Leader record—A “leader” record is a record that has one or moretrailer records, but the leader record itself may be a trailer toanother record. A “lead” record is a leader record that is not a trailerto any other record.

[0075] Trailer record—A record that points or links to a leader record.

[0076] Denigrated link—A link where a user has decided that a currentlink, such as an unconfirmed, confirmed, or certified link is incorrect,e.g., because the linked records do not in fact correspond to the samepatient. A denigrated link may thus be created in place of the incorrectlink.

[0077] Indirect link—In one embodiment, an indirect link may be createdwhen a record has multiple unconfirmed links to different records, andthe record is then confirmed as a trailer record to one of thesemultiple records. For example, suppose that record A has unconfirmedlinks to records B and C. If the unconfirmed link between A and B isthen changed to a confirmed link, where B is chosen as the leaderrecord, then an indirect link between C and B may be created. Indirectlinks are preferably non-directional links.

[0078] It is noted that the descriptions of the terms above refer to oneparticular embodiment of a Global Master Patient Index, and numerousalternative embodiments are contemplated. For example, the embodimentdescribed above utilizes two levels of review of links, i.e.,confirmation and certification. In various embodiments, any number oflevels of review may be provided for, as desired. For example, thecertification level may not be performed. Also, in one embodiment, anunconfirmed link may be changed directly to a certified link, thusbypassing the confirmation level.

[0079] As another example, links are referred to above as beingpairwise, i.e., each link may associate two records. In alternativeembodiments, links, such as non-directional links, may associate as manyrecords as desired.

[0080] As another example, the description above refers to the possiblecreation of denigrated links, e.g., to replace an incorrect link if itis determined that two records are not in fact duplicates. Inalternative embodiments, links may simply be removed if they arediscovered to be incorrect, without creating a denigrated link. However,denigrated links may be useful for audit purposes, to track the historyof the GMPI, and may also provide for a level of review after a user hasdenigrated an exiting link.

[0081] Also, it is noted that links may be represented and implementedin any of various ways. For example, a link between two records may berepresented by including information in each record, wherein thisinformation comprises information such as identifier informationspecifying the other member of the link, the type of link, the directionof the link (if the link is directional), etc. When operations areperformed on patient records, e.g., to lookup or create a new patientrecord, this information may then be checked to determine the existenceof any links. Various methods for the handling of links are describedbelow.

[0082]FIG. 3

[0083]FIG. 3 shows an example illustrating the various types of linksdescribed above. In this example, there is an unconfirmed link betweenpatient record F and patient record E. There is a confirmed or certifiedlink from patient record E to patient record B. There is a confirmed orcertified link from patient record D to patient record E. There is anindirect link between patient record F and patient record B. There is anunconfirmed link between patient record A and patient record B. There isa denigrated link between patient record A and patient record C.

[0084] The unconfirmed link (a non-directional link) between patientrecord A and patient record B indicates that these two records mightcorrespond to the same person. As described above, the system may haveautomatically detected that these two records are possible duplicates ofeach other and may have created the unconfirmed link to indicate this.Various methods for this automatic detection and flagging of possibleduplicate records are described below.

[0085] The confirmed or certified link (a directional link) from patientrecord E to patient record B indicates that these two records have beenconfirmed and/or certified by a user as corresponding to the sameperson. The link also indicates that record B has been determined to bethe most accurate, complete, or up-to-date record of the two. Forexample, the system may have previously established an unconfirmed linkbetween patient record B and patient record E. A user may have thennoticed this link, e.g., in response to performing a search for theperson corresponding to patient record B or E. The user may have theninspected the information of records B and E and/or may have consultedwith the patient, and may have decided that the information in record Bwas more current or more complete. Thus, the user may have established aconfirmed link from patient record E to patient record B. The user mayhave also created a confirmed link directly without converting anunconfirmed link to the confirmed link.

[0086] The confirmed or certified link from patient record D to patientrecord E indicates that record D has been confirmed and/or certified bya user as corresponding to the same person as record E. Since record Ecorresponds to the same person as record B, records D, E, and B allcorrespond to the same person. Record B is the lead record, and isconsidered the most accurate or current record for the patient.

[0087] It is noted that in alternative embodiments, when multiplerecords are linked together as in the example of record D, E, and B,links among the records may be adjusted to reduce the degree ofchaining. For example, the link from record D to record E could beremoved, and a link directly from record D to record B could be created.However, keeping the chain of links in place may have certainadvantages. For example, if the link from record E to record B iserroneously certified and has to be removed, the link from record D torecord E would still be in place.

[0088] The unconfirmed link between patient record E and patient recordF indicates that these two records might correspond to the same person,similarly as described above. Since record E corresponds to the sameperson as record B, records F and B also might correspond to the sameperson. This is indicated by the indirect link (a non-directional link)between record F and record B. For example, this indirect link may havebeen created when a previously unconfirmed link between E and B wasconfirmed as a directional link from E to B.

[0089] As described above, the denigrated link between patient record Aand patient record C that at one time a link such as an unconfirmed,confirmed or certified link existed between patient record A and patientrecord C but that link was then denigrated. For example, the system mayhave automatically detected that patient records A and C were duplicaterecords and may have established an unconfirmed link between therecords. Upon review by a person the person may have determined thatrecords A and C were in fact not matches, were not duplicate, and thusmay have requested the system to denigrate a link. As another example,the system may have established an unconfirmed link between the tworecords and an authorized person may have later confirmed the link basedupon information available at the time. However, upon further reviewanother user may have determined that the two records were in fact notduplicates and thus may have requested the system to denigrate the link.

[0090]FIG. 4

[0091]FIG. 4 is a state diagram illustrating various state changes thata link may undergo, according to one embodiment. It is noted that astate change of a link may be implemented in any of various ways. Forexample, a state change may involve removing an existing link andcreating a new type of link, or the state change may involve changinginformation representing the link, e.g., to indicate that the link isnow a different type of link, to specify a direction for a previouslynon-directional link, etc.

[0092] As shown by the arrow 500, a link may begin as an unconfirmedlink, e.g., an unconfirmed link that is automatically created by thesystem in response to detecting two patient records that are possibleduplicate records. As indicated by the arrow 502, this unconfirmed linkmay then become a confirmed link, e.g., in response to user inputconfirming the link and specifying a direction for the link. Asindicated by the arrow 504, a confirmed link may then be certified.

[0093] Referring now to arrow 508, an unconfirmed link may also bedenigrated. For example, as described above, a user may specify that thetwo records associated by the link do not actually correspond to thesame patient. As indicated by arrows 510 and 506, confirmed andcertified links may also be denigrated, e.g., if the confirmed orcertified link is discovered to be erroneous. As indicated by arrow 516,a denigrated link may be dissolved. For example, informationrepresenting the link may be removed entirely. It is noted that inalternative embodiments, links in various other states, such asconfirmed links, may also be dissolved directly if desired, withoutfirst being denigrated. However, arrow 514 illustrates one reason why adenigrated state may be useful. This arrow indicates that a denigratedlink may become a confirmed link. For example, a GMPI administrator mayreview links that were recently denigrated and may discover that anotheruser denigrated the link in error and may confirm (or certify) the link.

[0094] Arrow 518 indicates that indirect links may also be created.Indirect links are described above. In this case, the creation of theindirect link may involve the addition of a new link to a new record,rather than a state change of the existing link. For example, if recordA has unconfirmed links to records B and C, and the link from A to B isconfirmed, then an indirect link from C to B may be created, and theunconfirmed link between C and A may remain. However, the unconfirmedlink between C and A may also be removed, if desired.

[0095] An indirect link may be confirmed, as indicated by arrow 520 ordenigrated, as indicated by arrow 512.

[0096] It is noted that the state diagram of FIG. 4 illustrates oneembodiment of state changes a link may undergo. In alternativeembodiments, various additional states may be possible, various of thestates shown may not be possible, or paths between the states may bedifferent. For example, in one embodiment, an “unresolved” state is alsopossible. For example, in addition to confirming or denigrating anunconfirmed link, a user may also specify that the link is unresolved,e.g., indicating that the user does not know whether the link should beconfirmed or denigrated.

[0097]FIG. 5

[0098]FIG. 5 is a flowchart diagram illustrating one embodiment of amethod for automatically creating an unconfirmed link between twopatient records.

[0099] In step 460 user input specifying a new patient record isreceived. For example, a hospital clerk using a registration applicationmay create a new patient record when a patient checks in to thehospital.

[0100] In step 462, a search for potential duplicate patient records ofthe new patient record is performed. It is noted that this search may beperformed offline or in the background. In other words, the new patientrecord may be created and may be ready for immediate use by theapplication. As illustrated in FIG. 1, patient record information may bedistributed among different databases at different sites in a HealthData Network. The search may comprise searching patient records storedon a local system as well as searching for patient records located onsystems in other organizations. For example, the local computer systemmay interface with the client object server, as described above, tosearch for potential duplicate records. Thus, it may be desirable toperform the search for potential duplicate records as a background task,without forcing the user to wait for the search to be completed.

[0101] The determination of possible duplicate records may be performedin any of various ways. In one embodiment, Real World Primary Key (RWPK)information of the new patient record and the existing records is used.Real World Primary Key information may include information such as firstname, last name, social security number, gender, date of birth, etc. Anyof various criteria may be used in determining whether the RWPKs of tworecords match each other sufficiently closely for the records to beflagged as potential duplicate records. The match criteria used may beconfigurable by the user or by an administrator of the system.

[0102] In one embodiment the five RWPKs listed above may be used in thematch, and the match may be determined as follows:

[0103] Case 1: If two records match exactly on all five elements thenthe records are considered matches. It is noted that blank entries donot match blank entries in the other record.

[0104] Case 2: Exact match on first name, last name, and social securitynumber and either gender or date of birth, but only when the gender ordate of birth in the matching record in the database is NULL.

[0105] Case 3: Exact match on first name, last name, gender, and date ofbirth, but only when the social security number in the database is NULL.

[0106] This algorithm is of course exemplary, and any of various typesof match criteria or algorithms may be used. For example, the matchalgorithm may attempt to take possible typographic errors into account.

[0107] In step 464, if potential duplicate records were found in step462, then the system creates unconfirmed links between the new patientrecord and each potential duplicate record. As described above, theseunconfirmed links are preferably not directional links. The creation ofthe unconfirmed links may be performed in any of various ways, dependingon a particular implementation.

[0108] In one embodiment, the system may be operable to maintain auditinformation enabling users to track the history of the Global MasterPatient Index. Thus, in step 466 audit records indicating theunconfirmed links between the new patient record and the potentialduplicate records may be created.

[0109] Once the unconfirmed links between the new patient record and thepotential duplicate records are established, the links may be resolvedin various ways. For example, the next time a user looks up the newpatient record or one of the potential duplicate records, the user'sapplication may indicate that the record has unconfirmed links and maydisplay a user interface enabling the user to resolve the links, e.g.,by confirming or denigrating the links. Also, a user, such as a GMPIadministrator, may utilize an application enabled to perform a searchfor records with unconfirmed links and may then resolve the links.

[0110] In addition to creating unconfirmed links for a new patientrecord, FIG. 5 also illustrates a method for creating unconfirmed linksbetween two previously existing patient records. For example, in step468 input specifying changes to the RWPKs of an existing patient recordmay be received. For example, if a patient's SSN is discovered to beincorrectly listed in the patient record, the SSN may be corrected.

[0111] In response to the specified RWPK changes, in step 470, anyunconfirmed links for that patient record may be removed. Steps 462through 466 may then be performed similarly as described above, tosearch for potential duplicates of the record and create unconfirmedlinks to these potential duplicates.

[0112]FIG. 6

[0113] Applications that process patient records may be operable todetermine when a patient record has links and may use this informationin various ways. One situation when this information may be used is whena user performs a lookup of a patient record. FIG. 6 is a flowchartdiagram illustrating one embodiment of a method for looking up patientrecords in the GMPI, in response to user input.

[0114] In step 360, a patient record search is performed in response touser input. This user input may specify any of various types ofinformation that can be used to search for patient records, such as RWPKinformation or other information identifying a specific patient record.The search performed in step 360 may comprise searching for patientrecords on the user's local site as well as searching for patientrecords stored on remote sites. For example, the user's application mayinterface with the Client Object Server discussed above to perform thesearch.

[0115] In step 362, a list of patient records that were found thatmatched the specified user input may be displayed.

[0116] In step 364, user input selecting a patient record from thedisplayed list may be received.

[0117] In step 366, the method may determine whether the selectedpatient record has links to other records. If not, then the selectedpatient record may be displayed, as shown in step 368.

[0118] Otherwise, the method may determine whether the selected patientrecord is a lead record. If the selected patient record is not a leadrecord, then the selected record is a trailer record. In the preferredembodiment, when a trailer record is selected then the lead patientrecord for that trailer record is displayed instead of the selectedtrailer record. As shown in step 376, a message may be displayed toindicate to the user that this has occurred. It may be desirable todisplay the lead record since, as described above, the trailer recordwas determined to be less accurate or current than the lead record, forany of various reasons.

[0119] In step 372, the method determines whether the selected leadpatient record or the lead patient record of the selected trailer recordhas unconfirmed links. If not, then the lead patient record may beimmediately displayed, as shown in step 374.

[0120] Otherwise, in step 378, demographic information of the leadpatient record along with the demographic information of recordsassociated with the lead patient record by unconfirmed links may bedisplayed. A user interface enabling the user to enter confirmationinformation for the associations may also be displayed.

[0121] In step 380, user input specifying resolution information for theunconfirmed links of the lead patient record may be received. Forexample, the user may specify that a confirmed link should replace oneof the unconfirmed links and may specify the appropriate direction forthis confirmed link. A user may also denigrate an unconfirmed link orspecify that he does not know whether the link should be confirmed ordenigrated, thus changing the unconfirmed link to an unresolved link.Unresolved links may subsequently be treated similarly as unconfirmedlinks.

[0122] In step 382, the links among the records may modified asappropriate in response to the user input received in step 380. Variousembodiments of methods to perform these modifications are describedbelow.

[0123] Once the unconfirmed associations have been resolved, the leadpatient record may be displayed, or if the lead patient record wasconfirmed as a trailer to another record, this new lead record may bedisplayed, as shown in step 384.

[0124] It is noted that FIG. 6 represents one embodiment of a method forlooking up patient records, and in other embodiments various steps maybe added, combined, altered, removed, reordered, etc. For example,instead of entering resolution information via a user interface, theuser may have the option of skipping this process to immediately viewthe selected patient record. Also, this user interface may only bedisplayed for certain users that have permission to modify patientrecord links.

[0125]FIG. 7

[0126]FIG. 7 is a flowchart diagram illustrating one embodiment of amethod for confirming a link from a record A to a record B, wherein anon-directional link, such as an unconfirmed or denigrated link, existsbetween A and B.

[0127] In step 412, user input requesting to confirm the link isreceived. For example, as described above, when the user requests apatient record with unconfirmed links to be displayed, a user interfaceenabling the user to specify confirmation information for the patientrecord may be displayed, and the user may request to confirm anunconfirmed link via this user interface. Also, a user may confirm alink between A and B that was previously denigrated.

[0128] In step 414, a confirmed link from record A to record B may becreated. As shown in FIG. 7, this confirmed link is preferably adirectional link linking record A, i.e., the trailer record, to recordB, i.e., the leader record. In various embodiments, this confirmed linkmay be represented or implemented in any of various ways.

[0129] In step 416, any non-directional links between record A andrecord B may be removed. Although steps 414 and 416 are shown as twoseparate steps in FIG. 7, it is noted that in alternative embodimentsthe steps may be combined, e.g., by changing information specifying alink type between record A and record B.

[0130] As shown in step 418 and described above, when a link between tworecords is confirmed, indirect links may also be created. For example,as indicated in step 418, for each unconfirmed link between record A anda record D, where D is not B, an indirect link between D and B may becreated.

[0131] In one embodiment the system may be operable to maintain auditinformation for the GMPI. This audit information may enable GMPIadministrators to track the history of the GMPI as well as to view aspecific user's actions affecting the GMPI. Thus, in step 420 an auditrecord indicating the confirmed link from record A to record B may becreated.

[0132] In one embodiment, once a trailer record is confirmed into aleader record, the leader record may be modified to include informationof both the trailer and the leader record. For example, the leaderrecord may include employment data, medical data, insurance data,documents, contact data, consent data, lab orders data, lab resultreport data, diagnosis codes, etc., of both the leader and the trailerrecords.

[0133]FIG. 8

[0134]FIG. 8 is a flowchart diagram illustrating one embodiment of amethod for certifying a link from a record A to a record B, whereinrecord A is a trailer record with a confirmed link to a leader record B.

[0135] In step 430, user input requesting to certify the link from A toB is received. For example, GMPI administrators responsible forreviewing confirmed links may utilize an application to display recordshaving confirmed links and may certify one or more of these links.

[0136] In step 432, the link from record A to record B may be designatedas certified. For example, step 432 may involve storing informationindicating that the link has been certified. In alternative embodiments,step 432 may involve separate steps of removing the existing confirmedlink and creating a new certified link from A to B.

[0137] In step 434, an audit record for indicating the action ofcertifying the link from A to B may be created.

[0138]FIG. 9

[0139]FIG. 9 is a flowchart diagram illustrating one embodiment of amethod for creating a denigrated link between a patient record A and apatient record B, wherein there is an existing unconfirmed link betweenA and B. Denigrating an unconfirmed link may be desirable, for example,if the system automatically creates an unconfirmed link between tworecords determined to be potential duplicate records, but a user thendetermines that the records are not actually duplicates.

[0140] In step 436, user input requesting to denigrate the link may bereceived.

[0141] In step 438, a denigrated link between A and B may be created.This denigrated link is preferably a non-directional link, i.e., theorder of the link is not important.

[0142] In step 440, the existing unconfirmed link between record A andrecord B may be removed.

[0143] In step 442, an audit record indicating the creation of thedenigrated link between A and B may be created.

[0144]FIG. 10

[0145]FIG. 10 is a flowchart diagram illustrating one embodiment of amethod for denigrating a link between a record A and a record B, whereinrecord A is a trailer record with a directional link to leader record B.For example, the directional link from A to B may be a confirmed orcertified link, and it may be discovered that this link was confirmed orcertified in error.

[0146] In step 448, user input requesting to denigrate the directionallink is received.

[0147] In step 450, a denigrated link between A and B may be created.This denigrated link is preferably a non-directional link.

[0148] In step 452, the directional link from A to B may be removed.Thus, the trailer record A may become a lead patient record.

[0149] In step 454, an audit record indicating the creation of thedenigrated link may be created.

Laboratory Application

[0150] As discussed above, any of various types of applications used byany of various types of healthcare organizations may use GMPI patientrecord information. The remainder of this disclosure describes oneparticular application, i.e., a laboratory application, enabled toutilize a GMPI. This application enables various healthcare sites, suchas physician offices or hospitals, to connect to clinical laboratories,e.g., to electronically place lab orders and receive lab results.

[0151] This lab application includes several user interface displaysrelated to managing patient records and maintaining a GMPI. Inparticular, FIGS. 52-61 illustrate user interface screens related to oneembodiment of a GMPI.

Laboratory Orders and Results Application

[0152] After the user has successfully logged on to the lab orders andresults system, the main window appears, as shown in FIG. 11. Inaddition to standard user interface window components, the system mainwindow has several application-specific components, including drop-downmenus, an open items list, a desktop area, and a status bar.

[0153] Drop-down menus: The menu bar, located across the top of thesystem main window, provides access to all functions needed to use andmaintain the system. Various menu items are described below.

[0154] Open Items list: The Open Items list, located on the left side ofthe system window, shows all items that are open. As the user works withvarious items, such as lab requisitions, patient records, etc., theitems appear in the Open Items list. This feature allows the user toswitch back and forth between different items without having to closethe one the user is currently working on. FIG. 12 illustrates anexemplary Open Items list. In this illustration, the following items areopen: two requisitions under the Order section, two patient recordsunder the Patient section, and one patient group under the Report Groupsection. When the user log on to the system, the default item in theOpen Items list is Main Menu. At the bottom of the list, there is ahorizontal scroll bar that lets the user expand the view. To view anitem from the Open Items list, the icon next to the item is clicked. Thedark box around the item indicates that this is the item currentlydisplayed on the system desktop.

[0155] Desktop: The desktop area, the large area located on the rightside of the window, is where all screens of the application appear. Whenthe application first opens, the system desktop is occupied by the MainMenu desktop menu, as shown in FIG. 11. This desktop menu provides agraphic means of accessing the most frequently used functions of theapplication.

[0156] Status bar: The status bar, located at the bottom of the desktoparea, has two message panels. On the left side is the log on status,which displays the username used to log on at the workstation and thename of the active Health Data Network (HDN) Business. In the example ofFIG. 11, the user doc4 is logged on at the workstation and KennestoneHospital is the active HDN Business. On the right side is the labresults status, which displays the number of lab results that have notbeen viewed, i.e., new results electronically received from various labsbut not yet reviewed, and the number of those results that are abnormal.

Functional Architecture

[0157] In one embodiment the system includes the following functionalmodules: Orders, Results, Patients, User, and Admin. Each of thesemodules is described below.

Orders Module

[0158] In one embodiment, there are twelve basic functions to the Ordersmodule of the system:

[0159] Create Standard Requisition

[0160] Create Future Requisition

[0161] Access Requisitions

[0162] Manifest

[0163] ABN Form

[0164] Requisition Summary Report

[0165] Find Test Codes

[0166] Create Test Code

[0167] ICD-9 Codes

[0168] Lookup Labs

[0169] Manage Test Groups

[0170] Test Group Listing

[0171] These functions may be accessed from the Orders drop-down menu,as shown in FIG. 13 or from the Orders desktop menu, as shown in FIG.14. The Orders functions pertain to creating and managing lab orders.The Orders functions are described below.

Orders: Create Standard Requisition

[0172] The user creates a “standard” requisition when the patient is onsite and a specimen can be obtained right away. Once the requisition iscompleted, it can be sent to the lab. When the user creates a standardrequisition, a requisition number may automatically be generated by thesystem. If the user's system is configured for entering manualrequisition numbers, the system may also generate a requisition numberevery time the user creates a new requisition, but the user has theoption of changing the requisition number.

[0173] The Create Standard Requisition menu option enables the user to:

[0174] Create a standard requisition for an existing patient.

[0175] Create a standard requisition for a new patient.

[0176] Print or preview the requisition.

[0177] Delete the requisition.

[0178] Each standard requisition is divided into four pages ofinformation as shown in the following table: Page Name Includes . . .General Bill Type, patient demographics, and guarantor Billing Lab,primary care and referring physicians, ordering client information,collection date and time, and insurance Test Codes Diagnosis and testcodes Additional Specimen information, lab instructions, comments, and aInfo “Copy To” list.

[0179]FIG. 15 illustrates the General page of the Requisition window.Each page may be accessed by clicking on the appropriate tab at the topof the window.

Creating a Requisition

[0180]FIG. 16 is a flowchart diagram illustrating one embodiment of amethod for creating a standard requisition.

[0181] In step 300 a Requisition window is displayed. The Requisitionwindow includes fields for receiving user input specifying requisitioninformation. In one embodiment, the Requisition window includes tabs foraccessing a General page, a Billing page, a Test Codes page, and anAdditional Info page, as described above.

[0182] In step 302 user input specifying a patient is received. Forexample, FIG. 17 illustrates a Finding a Patient window. The patient maybe found by various identifiers, such as the name or social securitynumber, or a recently viewed patient may be chosen. If a requisition isto be created for a patient who does not yet have a patient record, thenthe user may create a new patient record. In one embodiment, the Findinga Patient window appears automatically in response to a request tocreate a requisition, before the Requisition window is displayed in step300.

[0183] In step 304, the record for the specified patient is received,and the record information is used to populate patient informationfields of the Requisition window. In one embodiment, the system may beoperable to maintain a Global Master Patient Index (GMPI) thatintegrates patient record information for multiple Health Data NetworkBusinesses. Thus, this GMPI information may be used in retrieving theappropriate patient record.

[0184] In step 306, user input specifying general requisitioninformation is received, such as contact information for the patient,guarantor information, etc. FIG. 15 illustrates an exemplary userinterface for receiving this general information, i.e., the General pageof the Requisition window displayed in step 300.

[0185] The FIG. 15 user interface also includes a field for specifying aBill type, such as client, patient, or third party. If a requisition waspreviously created for the specified patient, relative information fromthat requisition, such as the Bill Type, also populates the appropriatefields. Otherwise, the remaining fields are populated with the defaultvalues.

[0186] In step 308, user input specifying billing information for therequisition is received. FIG. 18 illustrates an exemplary user interfacefor receiving this billing information, i.e., the Billing page of theRequisition window displayed in step 300. In one embodiment, when theuser moves from the General page to another page, such as the Billingpage, any data the user has entered in the patient information fields isautomatically saved in the patient's record. A message may appear,advising the user that all requisitions will now use the new patientinformation. In one embodiment, the user may be able to choose whetheror not to modify the patient record in this way. It is noted that thefields included in the user interface that is displayed in step 308 maydepend on the Bill Type chosen by the user.

[0187] In step 310, user input specifying diagnosis codes for therequisition is received. FIG. 19 illustrates an exemplary user interfacefor receiving this diagnosis code information, i.e., the Test Codes pageof the Requisition window displayed in step 300. The user may enter alist of diagnosis codes, such as ICD-9 codes that specify thecaregiver's diagnosis for the patient.

[0188] In step 312, user input specifying test codes for the requisitionis received. FIG. 19 illustrates an exemplary user interface forreceiving this test code information, i.e., the Test Codes page of theRequisition window displayed in step 300. The user may enter a list oftest codes specifying the desired lab tests to perform on the patientspecimen(s).

[0189] In step 314, user input specifying a list of caregivers to whomto electronically send the results of the lab tests is received. FIG. 20illustrates an exemplary user interface for receiving this information,i.e., the Additional Info page of the Requisition window displayed instep 300.

[0190] As shown in the user interface of FIG. 20, user input specifyingother information for the requisition may also be received, such as labinstructions, information regarding the patient specimens collected,etc.

[0191] In step 316, the requisition is validated by the system, e.g., inresponse to receiving user input specifying that the user is doneentering information. If there are errors in the information entered forthe requisition, an error message may appear, and the user may berequired to correct the errors.

[0192] In one embodiment, when the bill type chosen is Third Party andthe patient insurance is for a Medicare payer and the user selected atest code that is not LCP-compliant or FDA-approved, the ABN Dialog boxappears.

[0193] If the patient has already signed an ABN Form, the user selectsYes next to The Patient has signed an ABN Form. The PatientAcknowledgment of Non-Covered Services statement will print at thebottom of the requisition.

[0194] If the patient has not already signed an ABN Form, the userselects No next to The Patient has signed an ABN Form. If the patient isin the user's office and can sign an ABN Form, the user selects Yes nextto Patient Is Here to Sign an ABN form. The Patient Acknowledgment ofNon-Covered Services statement will print at the bottom of therequisition. The user should then have the patient sign the statement.

[0195] Otherwise, the user selects No next to Patient Is Here to Sign anABN form. If there are other medically appropriate diagnosis codes inthe patient's chart for this date of service, then the user may specifyYes, and the requisition window appears, allowing the user to click onthe Test Codes page and select appropriate ICD-9 Diagnosis Codes for theselected tests. Otherwise, the user specifies No, and an ABN Warningappears.

[0196] In step 318, user input specifying a number of specimen labels toprint may be specified, and the system may then print the specimenlabels. The specimen labels may include information from the requisitionthat facilitates efficient handling of the specimen.

[0197] In step 320, the requisition information may be stored. The usermay later use the Access Requisitions option of the Orders menu toselect and electronically send the requisitions, e.g., by interfacingwith the middleware COS server 110 illustrated in FIG. 2.

Requisition Window Fields

[0198] The following sections describe fields for the four pages of theexemplary Requisition Window described above (i.e., the General page,Billing page, Test Codes page, and Additional Info page).

[0199] The procedure for entering the information on the pages of theRequisition window is determined by the bill type selected on theGeneral page. In one embodiment, there are three possible bill types, asshown in the following table: Bill Type The lab will bill . . . ClientThe client (provider or physician) ordering the tests Patient Thepatient's guarantor Third Party The patient's insurance

[0200] If the user has previously created a requisition for the selectedpatient, the Bill Type field may be populated with the selection made onthe last requisition. If the user has not previously created arequisition for the selected patient, the field may be populated withthe default value for the HDN Business the user is logged into.

[0201] A bill type of Client means that the client will be billed forservices rendered. No additional billing information will be required.

[0202] A bill type of Patient means that the patient will be billed forservices rendered. The user will need to enter guarantor information forthe patient on the Billing page.

[0203] A bill type of Third Party means that an insurer will be billedfor services rendered. The user will need to enter insured and payerinformation on the Billing page.

Requisition—General Page

[0204] The General page includes basic patient demographic information,as well as a field for the Bill Type. As shown in FIG. 15, The followingfields may be included on the General page: Account # (The patient'saccount number); Address; Age; Birth Date; City ; First Name; HomePhone; Last Name; Middle Name; Operator ID (The identifier for theoperator creating the requisition); Sex; SSN; State; Zip.

[0205] For various of the above fields, if the user selects an existingpatient and the information exists in their record, the field may beautomatically populated. Changes made to the field may also change thepatient's existing record.

[0206] The General page also includes a set of fields for enteringGuarantor information, e.g., for the name and contact information forthe Guarantor. The fields are only active if the value in the Bill Typefield is Patient. If the user has previously created requisitions forthe selected patient where the Bill Type was set to Patient, theguarantor information from the last requisition may populate the fields.If the user has not previously created requisitions for the selectedpatient or if this is a new patient, the fields are blank. If the userselects an existing guarantor and the information exists in theirrecord, the fields are automatically populated.

Requisition—Billing Page

[0207] The Billing page (see FIG. 18) includes a set of fields forentering patient insurance information. These fields are only active ifthe value in the Bill Type field on the General page is set to ThirdParty. If the user has previously created requisitions for the selectedpatient, the insurance information from the last requisition populatesthe fields. If the user has not previously created requisitions for theselected patient, these fields are blank.

[0208] Insured information fields—The Billing page may include a set offields for information related to the Insured, such as: address, city,first name, last name, phone number, relationship (for specifying thepatient's relationship to the insured), etc.

[0209] Payer information fields—The Billing page may include a set offields for information related to the Payer, such as: address, city,group number (the group number of the policy for the selected patientinsurance), insurance code (The identifying code for the payer),member/policy number (The member or policy number for the selectedpatient insurance), name (he name of the payer for the selected patientinsurance), state, zip, etc.

[0210] Order information fields—The Billing page may also includeselected order information, including Performing Lab, RequisitionStatus, Ordering Client, Client ID, and Referring Physician. If the userhas previously created requisitions for the selected patient, the orderinformation from the last requisition may populate the fields. If theuser has not previously created requisitions for the selected patient,the fields are blank.

[0211] Before a physician or provider can order a test, they must besetup in the system. The Health Data Network (HDN) Business that isassociated with the physician or provider must also be setup to doelectronic transactions. Otherwise, when the user tries to find the nameof the ordering physician, the system will not be able to locate it anda pop up window with the message “No records were found” will appear.

[0212] The ordering physician may or may not have a Client ID number. Ifthe physician has a Client ID number, the system automatically displaysthat number in the Ordering Physician Client ID field. Otherwise, itdisplays the HDN Business Client ID. An administrator may be responsiblefor setting up the links between providers and caregivers and assigningClient IDs to those caregivers. These assignments are made through theManage Security/HDN Businesses and Manage Businesses/Providersfunctions, which are accessed through the Admin menu, as describedbelow.

[0213] The system may automatically generate and assign a uniquerequisition number to each new requisition. If the user's system isconfigured for entering manual requisition numbers, the user has theoption of changing the requisition number. This requisition numberappears displayed on the title bar of the patient window.

[0214] The billing information fields may include the following fields,as shown in FIG. 18: Field Description Client ID The ordering physicianlab client identifier. If the ordering physician does not have aspecific lab client ID, the default client ID of the active HDN Businessis used. Collection The date and time when the sample was collected.Date/Time Ordering The physician ordering the tests. The physician mustbe a Client lab client or associated with a provider who is a labclient. If the patient's Primary Care Physician is a lab client, thisfield is populated with that physician's name. Performing The lab thatwill perform the tests. This field is Lab automatically populated withthe default lab set up for the active HDN Business. Primary Care ThePrimary Care Physician for the patient. If the user Physician selects aclient physician as the patient's Primary Care Physician, that physicianwill be used as the default Ordering and Referring physician on theOrder Info page. Referring The physician that referred the patient tothe ordering Physician physician. The ordering physician isautomatically used for this field. The referring physician does not haveto be a client of the lab. Requisition The number assigned by the systemfor the requisition. Number Requisition The status of the requisition.The default status for a Status standard requisition is “entered”. Thedefault status for a future requisition is “inactive”. STAT Checkingthis field indicates that the ordering physician wants STAT processingof this order

Requisition—Test Codes Page

[0215] The Test Codes page (see FIG. 19) includes fields for enteringlaboratory test code information for the requisition, such as ICD-9diagnosis codes and test codes.

[0216] ICD-9 stands for International Classification of Diseases version9. ICD-9 coding is recommended for use in all clinical settings and isrequired for reporting diagnoses and diseases to all U.S. Public HealthService and Health Care Financing Administration programs. The user canretrieve ICD-9 and test codes from the user's Preferred List of codes byselecting Preferred List from the field control menu located next to theeach input field.

[0217] The ICD-9 code list may include the following columns, as shownin FIG. 19: Description The description of the ICD-9 Diagnosis CodeICD-9 Code The ICD-9 Diagnosis Code User A user-defined description forthe ICD-9 Diagnosis Code Description

[0218] Test codes are used to specify what tests to perform on apatient. When the user prints or previews a requisition, the user willsee the tests codes listed under the heading PROFILE/TESTS.

[0219] If a selected test code includes Ask-at-Order-Entry (AOE)questions, the first question in a series appears on the screen. Theuser may then answer the question and click Continue. Questions continueto appear until the user has answered them all. After the last questionis answered, the Test Codes page appears.

[0220] If the user selects a PAP test, the PAP Information windowappears. The user enters the appropriate information in each of thefields.

[0221] If the user attempts to add a test code that is already on thelist, the Duplicate Found dialog box appears.

[0222] The test code list may include the following columns, as shown inFIG. 19: Description The description of the test code Expiration DateThe expiration date of the test code Special Test Indicates whether ornot the specimen for the test code requires special handling Test CodeThe test code

Requisition—Additional Info Page

[0223] The Additional Info page (see FIG. 20) includes fields forentering additional information regarding the requisition. The testcodes the user selects on the Test Codes page, the Bill Type setting onthe General page and the type of the active HDN Business (e.g.,“physician practice” or “hospital”) determines which of these fields isrequired. For example, when the user orders a test that requires 24 hoururine samples, the user is asked a series of questions such as thepatient's height, weight and urine volume. In this case, the user wouldcomplete these fields: Lab Instructions, Urine Volume ML, and Urine Hrs,and any other information relevant to the patient or test beingperformed.

[0224] The Additional Info page may include the following fields, asshown in FIG. 20: Field Description Fasting Hrs The number of hours thepatient fasted before the specimen was collected Hospital ID If theactive HDN Business is a hospital, this is the hospital's identifier LabInstructions These are specific instructions from the ordering physicianto the lab for tests ordered Lab Reference The lab reference Location Ifthe active HDN Business is a hospital and the patient has been admitted,this is the patient's location Phone in Results Selecting this fieldindicates that the ordering physician wants the lab to phone in theresults, as well as return them electronically. In this field, the usermust enter the phone number that the user wants the lab to call PrepaidAmount The amount the patient has prepaid for the tests ordered ReportComments This field is for any comments from the ordering physician thatneed to accompany the tests ordered Room # If the active HDN Business isa hospital and the patient has been admitted, this is the patient's roomnumber Send Copies to This is a list of physicians that should be copiedon the results. All physicians on this list must be a lab client orassociated with an HDN Business that is a lab client Shift If the activeHDN Business is a hospital and the patient has been admitted, this isthe shift which collected the specimen Urine Hrs This is the number ofhours for urine specimens Urine Volume ML This is the number ofmilliliters of urine collected for the tests

Orders: Create Future Requisition

[0225] The Create Future Requisition menu option of the Orders menuenables the user to prepare a requisition before the patient arrives orthe specimen is received. A future requisition can also be printed andgiven to a patient to take to a lab.

[0226] Future requisitions are stored in the system until the specimenis collected. When the user creates a future requisition, a requisitionnumber is automatically generated by the system. If the user's system isconfigured for entering manual requisition numbers, the user has theoption of changing the requisition number.

[0227] The distinction between standard and future requisition typesexists to keep track of those requisitions whose specimens have not beencollected yet. The system accomplishes this by assigning a differentstatus to each type. When a standard requisition is created it has anEntered status. When a future requisition is entered its status isInactive. The Create Future Requisition menu option enables the user to:

[0228] Create a future requisition for an existing patient

[0229] Create a future requisition for a new patient

[0230] Print or preview the requisition

[0231] Delete the requisition

[0232] Activate the requisition, which tells the system that a futurerequisition can be sent to the lab for processing

[0233] Each future requisition is divided into four pages ofinformation, similar to the four pages described above with reference tostandard requisitions. The procedure for entering the information onthese pages is determined by the bill type selected on the Patient page.There are three possible bill types: Client, Patient, and Third Party.

[0234] At the bottom of every page in the Create Future Requisitionfunction there is a row of buttons which correspond to the followingfunctions: Print Opens the Print dialog, allowing the user to print therequisition and specimen labels. Help Opens the help topic for thecurrent active page. Delete Deletes the requisition. Activate Activatesthe requisition (changes the status from “inactive” to “entered”) sothat it may be sent. <<Back Moves to the previous page of therequisition. Next>> Moves to the next page of the requisition. SaveSaves the requisition. The user cannot save a requisition until all therequired fields are complete. Close Closes the requisition.

[0235] Creating a future requisition follows a similar procedure asdescribed above for creating standard requisitions. As needed, the useractivates future requisitions through the Access Requisitions option ofthe Orders menu.

Orders: Access Requisitions

[0236] The Access Requisitions menu option of the Orders menu enablesthe user to keep track of all the requisitions generated from the user'soffice and their current status. From the Access Requisitions menuoption the user can:

[0237] View a list of requisitions

[0238] View all details of a requisition

[0239] Modify a requisition

[0240] Print a list of requisitions

[0241] Print details of a requisition

[0242] Delete a requisition if it has not been sent to a lab

[0243] Send one or more requisitions

[0244] Send all requisitions

[0245] The user can find requisitions by using requisition informationor by using patient information. Each method enables the user to usedifferent parameters to narrow down the results of the user's search.For example, the user may want to generate a list of all the enteredrequisitions whose specimens were collected within a certain timeperiod, or the user may want to obtain a list of all the requisitionsthat were ordered by a physician for a patient. Also, there may be timeswhen the user needs to add more information to an existing requisitionthat has not been transmitted to a lab yet, as in the case where adoctor requests an additional test for a patient or the user needs tochange information on the patient's insurance coverage. In both cases,the user would search for the requisition, make the required changes toit and then save it. A doctor may also decide to cancel a requisition,in which case, the user would delete that requisition because it is nolonger needed.

[0246] From the General page, the user can find a requisition using oneor more of the following search criteria: Requisition #; RequisitionStatus; Ordering Provider; Lab; Collection Date Range; and Stat Only.FIG. 21 illustrates the General page of the Access Requisitions window.

[0247] From the page labeled By Patient Info, the user can find arequisition using one or more of the following search criteria: Patient;Ordering Physician; Referring Physician; Bill Type; Client ID; andAnonymous Requisition.

[0248] The user can generate a list of requisitions stored in the systemby specifying at least one of the search parameters in the AccessRequisition window. Requisitions can be modified and/or deleted as longas they have not been sent to the lab for processing. The requisitionstatus indicates whether a requisition has already been transmitted.

Orders: Manifest

[0249] The Manifest menu option of the Orders menu enables the user togenerate a manifest manually for those cases where the original manifestmay be misplaced or if the user just wants to have an extra copy of themanifest for the user's records. A manifest is used by the submittingclient to verify that all specimens are accounted for. The manifestlists all the tests ordered on each requisition, and it provides aconvenient means for both the courier, who picks up the specimens, andthe receiving laboratory to verify that the correct number of specimensand requisitions is received.

[0250] The Manifest window is shown in FIG. 22. Clicking the Find Nowbutton on the Manifest window without specifying any search criteriagenerates a listing of all requisitions with a ‘Transmitted’ status inthe user's active HDN Business. The user can narrow down the resultslist by specifying one or more of the following search criteria: StatOnly; Inclusion; Sort Order; and Collection Date/Time Range.

[0251] The search results appear listed under the following columnheadings: Requisition No.; Patient Name; Patient Account #; Status; andOrdering Client. When the results of the user's search appear on theManifest window, the user can selectively highlight those requisitionsthe user wants to include on the manifest. A manifest can be previewedor printed. The first page of the report is a header page that shows thename of the ordering provider and the search criteria that were used togenerate the manifest. The rest of the report displays a list of all therequisitions in the manifest under the following column headings:

[0252] Control #

[0253] Pat. Account

[0254] Patient Name

[0255] Age

[0256] Sex

[0257] Hosp ID

[0258] Lab Ref.

[0259] Collection Date/Time

[0260] Urine Vol. & Hrs.

[0261] Test

[0262] Operator ID

[0263] Results Received

Orders: ABN Form

[0264] The ABN Form menu option enables the user to access an AdvancedBeneficiary Notice (ABN) Form. An Advanced Beneficiary Notice is aprinted statement that contains a list of tests not covered by thepayer. By signing an ABN form, the patient or the insured acceptsfinancial responsibility for those tests that are not covered by thepayer. For example, Medicare has limited coverage. An ABN form isgenerated when the user enters information on the Requisition Test Codespage. If the test code the user enters is for a limited coverage testand the diagnosis code is not approved to cover that test, the systemprompts the user to answer questions pertaining to the ABN and have thepatient sign the statement that is printed at the bottom of therequisition.

[0265] The only search criteria required to generate this form is thepayer or insurance company name. An optional header page can be includedas the first page in the report showing:

[0266] Date and time when the form is printed

[0267] Name of the user generating the form

[0268] Comment line

[0269] Search criteria used to generate the form

[0270] Once the ABN form is complete and signed by the patient, a copyof it can be sent to the lab along with the accompanying requisition andspecimen.

[0271]FIG. 23 illustrates the ABN Form window. A print preview of theABN form may be displayed. FIG. 24 illustrates the ABN Form PrintPreview window.

Orders: Requisition Summary Report

[0272] The Requisition Summary Report menu option of the Orders menuenables the user to generate a list of requisitions for any date range,patient, ordering physician and requisition status. The user can alsoget a listing of all requisitions by just running the report withoutspecifying any of these search parameters. However, without specifyingsome search criteria the report may be very large.

[0273] The Report page, shown in FIG. 25, lets the user specify a headerpage as a configurable option. The header pages shows:

[0274] Date and time of the report

[0275] Name of the user running the report

[0276] Comment line

[0277] Search criteria used to generate the report

[0278] The Format Options page lets the user specify how the user wantthe report to be sorted. The report can be sorted by:

[0279] Patient Last Name

[0280] Requisition Number

[0281] Patient Account Number

[0282] The Requisition Summary Report can be either previewed orprinted. FIG. 26 illustrates the Requisition Summary Print Previewwindow. The report is printed and displayed in landscape mode with thefollowing column headings:

[0283] Control # (same as Requisition #)

[0284] Status

[0285] Pat. Account

[0286] Patient Name

[0287] Age

[0288] Sex

[0289] Hospital ID

[0290] Lab Reference

[0291] Collection Date/Time

[0292] Test

[0293] Description

[0294] In addition, the system prints each ordering physician's fullname and Client ID at the beginning of each page in the report.

Orders: Find Test Codes

[0295] The Find Test Codes menu option of the Orders menu allows theuser to locate test codes for labs. When selected, the Find Test Codeswindow appears, as shown in FIG. 27. The user can enter the searchcriteria needed to best locate the test code the user wants to find andclick Find Now to perform the search. The results appear in the list atthe bottom of the window. The user can then locate and select the testcode(s) the user wants to use. The user can also add test codes to aPreferred List of Test Codes.

Orders: Create Test Code

[0296] The Create Test Code menu option of the Orders menu allows theuser to create new test codes for labs. When selected, a blank Test CodeDetails window appears, as shown in FIG. 28, allowing the user to fillin the fields to create a new test code.

Orders: ICD-9 Codes

[0297] The ICD-9 Codes menu option of the Orders menu allows the user tolocate ICD-9 codes. When selected, the Find ICD-9 Code window appears,as shown in FIG. 29. The user can enter the search criteria needed tobest locate the ICD-9 code(s) the user wants to find and click Find Nowto perform the search. The results appear in the list at the bottom ofthe window. The user can then locate and select the ICD-9(s) the userwants to use. The user can also add ICD-9 codes to a Preferred List ofICD-9 Codes.

Orders: Lookup Labs

[0298] The Lookup Labs menu option of the Orders menu allows the user tolocate and select labs available for the user's use, e.g., toelectronically send requisitions to the labs. When selected, the LookupLabs window appears, as shown in FIG. 30. The user can click the Labfield control button and choose Select to display a list of availablelabs.

Orders: Manage Test Groups

[0299] The Manage Test Groups menu option of the Orders menu allowsmultiple tests to be grouped together for the purpose of ordering. Eachtest group is identified by a code and includes multiple tests. Beingable to enter test group codes instead of individual test codes savesthe user time and promotes accuracy when creating a requisition, e.g.,by preventing erroneous test code from being entered and ensuring thatrequired codes are not forgotten.

[0300] Test Groups also help the user simplify the task of creatingrequisitions by enabling the user to work with only those test codesthat are specific to a group of patients in the user's practice. Forexample, the tests performed in an allergy/immunology practice will morethan likely differ from those performed at an office specializing incardiovascular diseases. Also, there may be multiple physicians in apractice, and each physician may handle specific types of patients whorequire different types of tests.

[0301] When the user chooses Manage Test Groups from the Orders menu,the Test Group Management window appears, as shown in FIG. 31. From thiswindow, the user can:

[0302] List all test groups

[0303] List all the test codes in a test group

[0304] Create New test groups

[0305] Add a new code to a test group

[0306] View/Modify details in a test group

[0307] Remove a test group

[0308] Remove a test from a test group

[0309] Print a list of all test groups

[0310] Print details on a specific test group

Orders: Test Group Listing

[0311] The Test Group Listing menu option of the Orders menu allows theuser to preview or print a list of all the test groups for each providerthat are created through the Manage Test Groups function. The items onthe list appear sorted in alphabetical order. A header page is aconfigurable option. The header pages shows:

[0312] Date and time of the report

[0313] Name of the user running the report

[0314] Comment line

[0315] Search criteria used to generate the report

[0316]FIG. 32 illustrates the Test Group Listing window.

Results Module

[0317] In on embodiment, there are six basic functions to the Resultsmodule of the system:

[0318] View Results

[0319] View Result Reports

[0320] Cumulative Report

[0321] Results Summary Report

[0322] Manage Report Groups

[0323] Report Group Listing

[0324] These functions may be accessed through the Results drop-downmenu, as shown in FIG. 33, or the Results desktop menu (not shown). TheResults functions pertain to reviewing and managing lab results. TheResults functions are described below.

Results: View Results

[0325] The View Results menu option of the Results menu providesflexible, on-demand reporting capability for current and historical testdata. This reporting feature enables a physician to track a patient'sprogress over a period of time. The View Results window is shown in FIG.34. This window enables the user to generate a listing of results basedon the following search criteria: Patient Account; Patient; AnalyteCodes; Report Codes; Profile Codes; Collection Date Range; and ResultDate Range. The user may be required to enter

[0326] The Format Options page of the View Results window lets the userspecify how the user want the results to be sorted. The report can besorted in reverse chronological order or in chronological order.

[0327] The Results Report can be previewed or printed. The report may beprinted and displayed in landscape mode with the following columnheadings:

[0328] Collection Date/Time

[0329] Requisition#

[0330] Test/Description

[0331] Result

[0332] Normal Range

[0333] Units

[0334] Specimen Type

[0335] Reported Date/Time

[0336] A header page is a configurable option for a Results Report. Theheader page shows:

[0337] Date and time of the report

[0338] Name of the user running the report

[0339] Comment line

[0340] Search criteria used to generate the report

[0341] In addition, the system prints detailed information on theselected patient at the top left hand comer of the report which includespatient name, patient account, patient age and sex. FIG. 35 illustratesa Results Report Print Preview Window.

Results: View Result Reports

[0342] As described above, the user interface windows of the applicationdisplay a status message at the bottom right comer of the screen showing“Not Viewed Results” and “Abnormal Results”. This status message tellsthe user if any new test results have been electronically received. Italso tells the user if any of those test results are abnormal.

[0343] The View Result Reports function enables the user to preview andprint electronic reports of lab results. The user can use a variety ofsearch criteria to narrow down the results of the user's search.

[0344]FIG. 36 illustrates the General page of the Find Result Reportswindow. From the General page the user can specify one or more of thefollowing:

[0345] Patient

[0346] Result Type

[0347] Performing Lab

[0348] Performing Lab Type

[0349] Result Date Range

[0350] Accession#

[0351] Viewed Only

[0352]FIG. 37 illustrates the By Requisition page of the Find ResultReports window. From the By Requisition page the user can specify one ormore of the following:

[0353] Requisition #

[0354] Ordering Physician

[0355] Referring Physician

[0356] Ordering Provider (this field is populated by the system with thename of the currently active HDN Business)

[0357] Result Status

[0358] The results of the user's search are displayed under thefollowing column headings:

[0359] Req. #

[0360] Acc. #

[0361] Patient Name

[0362] Collection Date

[0363] Status

[0364] Abnormal

[0365] Result Date

[0366] Ordering Physician Name

[0367] Provider

[0368] Lab

[0369] Viewed

[0370] Once a list of result reports appears on the screen, the user canselect one or more of the results to view or print them, e.g., byhighlighting the desired result(s) and clicking the View/Print Resultbutton. When the user clicks the View/Print Result button, a PrintOptions window appears. This is where the user specifies whether thereport should show abnormal high/abnormal low flags next to each resultand whether the user wants to preview or print the report.

Results: Cumulative Report

[0371] The Cumulative Report menu option of the Results menu allows theuser to review and print analyte results for a patient over a specifiedperiod of time. This reporting tool provides a physician the ability toexamine a patient's progress over a period of time and simplifies thecollecting, organizing and filing of test results for a patient orpatients. The main difference between Cumulative Reports and ViewResults Reports is in the way information is displayed. In a CumulativeReport the results for a single analyte appear listed horizontally overseveral date/time column headings. Also a Cumulative Report does notshow requisition numbers or additional information on a test such asnormal range, units and specimen type.

[0372]FIG. 38 illustrates the Report page Cumulative Reports window. Theuser can specify the following criteria to narrow down the results ofthe search:

[0373] Date Range

[0374] Patient

[0375] Patient Group

[0376] Shift

[0377] Location

[0378] Ordering Physician

[0379] Report Group

[0380]FIG. 39 illustrates the Format Options page of the CumulativeReport window. In the Format Options page, the user can select thefollowing options to display a Cumulative report:

[0381] Display Date/Time horizontally and Analyte Code vertically orvice versa

[0382] Display results in chronological order or reverse chronologicalorder

[0383] Title (An optional free text field where the user can enter areport title)

[0384]FIG. 40 illustrates the Print Options page of the CumulativeReport window. In the Print Options page, the user specifies whatadditional supplemental information to include in the report. The usermay select from the following three sections to include in the report.

[0385] Section I—Results Summary

[0386] Section II—Text and Notes

[0387] Section III—Performing Laboratories

[0388] The Results Summary section shows a listing of analyte resultsfor a patient over a period of time. This is the most importantcomponent in a cumulative report. Results appear under theircorresponding collection date/time column headings. Abnormal results areflagged with an H for high or L for Low.

[0389] The Text and Notes section of the report displays miscellaneousnotes and remarks associated with test results. Text and notes canoriginate from report comments the user enters on the Additional Infopage of a requisition or from an authorized user at the lab such as alab director, medical technologist, pathologist or microbiologist.Nonnumeric results such as “positive” or “abnormal” appear in the Textand Notes section. For example, if the results of a CBC test reveal alow red blood cell count, the lab technician may include a message alongwith the results such as: “R/O anemia. A complete blood count is used asa screening test for various states such as anemia, leukemia andinflammatory disease”.

[0390] The Performing Laboratories section lists the names and addressesof all the laboratories from which the test results were obtained.

[0391] After selecting the report search criteria, format options andprint options, the results can be previewed or printed. When the resultsare previewed, an Analyte Result window appears, as shown in FIG. 41.Results are displayed one patient at a time. The top part of the displayshows a heading with the patient's name, date of birth, sex and daterange. Below the heading are the results for each analyte displayed overa period of time. The bottom part of the display contains the followingset of buttons: Graph This button displays analyte results in a graph.The graph can be previewed and printed. Annotate This button opens afree text window where the user can enter comments. Comments can beviewed, modified and deleted. View Message This button displays a windowwith text messages that originate from TopLab. If there are no messagesfrom TopLab, the message results window box appears empty. View DetailThis button displays an Analyte Result Detail window that shows detailedinformation on the analyte result selected. Print Report This buttonprints the Analyte Result report that appears on the screen. <<Back Thisbutton displays the results of the previous patient. Next>> This buttondisplays the results of the next patient. Close This button closes theAnalyte Result window.

Results: Results Summary Report

[0392] The Results Summary Report menu option of the Results menu allowsthe user to generate a multiple patient report designed to present a onetime summary of any results received that meet a certain criteria. FIG.42 illustrates the Results Summary Report window. The user can customizethe search criteria to produce only the results that best meet theuser's practice requirements. For example, the user can generate alisting of all the patients who had abnormal or high HDL cholesterolreadings over a period of time.

[0393] The user can specify the following criteria to narrow down theresults of the user's search:

[0394] Date Range (dates of the first and last results to include in thereport)

[0395] Patient (a list of patients whose to include in the report.)

[0396] Patient Group (a list of patient groups whose results to includein the report.)

[0397] Shift (the shift that collected the specimen for the results tobe included in the report)

[0398] Location (the location where the specimen was collected for theresults to include in the report.)

[0399] Ordering Physician (a list of ordering physicians of therequisitions corresponding to the results to include in the report.)

[0400] Report Group (a list of report groups to include in the report)

[0401] Results are printed per patient. The selection of analytes forthe report is done using the report groups. A header page is aconfigurable option. The header pages shows:

[0402] Date and time of the report

[0403] Name of the user running the report

[0404] Comment line

[0405] Search criteria used to generate the report

[0406]FIG. 43 illustrates a Results Summary Report Print Preview window.

[0407] In the Format Options page of the Results Summary Report window,the user can select the following options to display a Results Summaryreport:

[0408] Format Style (Tabular or List)

[0409] Clinical Status (Normal, Abnormal or Both)

[0410] Sort Order (Patient Name or Account Number)

[0411] Title (An optional free text field where the user can specify areport title)

Results: Manage Report Groups

[0412] Report Groups are user-defined collections of analyte codes,report codes and profile codes. The Manage Report Groups menu option ofthe Results menu allows the user to create and maintain these reportgroups.

[0413] Report Groups are used to generate Results Summary Reports andCumulative Reports. Information obtained from these reports can be usedto schedule patient visits in advance, gather valuable statisticalinformation, and identify trends in a patient population. A ResultsSummary Report is a listing of all the test results that meet a certaincriteria such as date range, patient, patient group, shift, location,ordering physician and report group. A Cumulative Report allows the userto review and print information on any analyte or group of analytes, fora particular patient or group of patients over a specific time period.

[0414] When the user chooses Manage Report Groups from the Results menu,the Report Group Management window appears, as shown in FIG. 44. Fromthis window, the user can:

[0415] List all report groups

[0416] List all the analyte codes in a report group

[0417] Create New report groups

[0418] Add a new code to a report group

[0419] View/Modify details in a report group

[0420] Remove a report group

[0421] Remove an analyte code from a report group.

[0422] Print a list of all report groups

[0423] Print details on a specific report group

[0424] The user can build a report group by selecting any combination ofone or more profiles, report codes or analyte codes. Once a Report Grouphas been defined and given a name, it appears listed in the Report GroupManagement window. Regardless of what method the user uses to build areport group (by profile, report or analyte code), the report groupalways shows the individual analyte codes that make up the report groupalong with their individual name and description.

Results: Report Group Listing

[0425] The Report Group Listing menu option of the Results menu allowsthe user to preview or print a list of all the report groups for eachprovider that are created through the Manage Report Groups function. Theitems on the list appear sorted in alphabetical order. A header page isa configurable option. The header pages shows:

[0426] Date and time of the report

[0427] Name of the user running the report

[0428] Comment line

[0429] Search criteria used to generate the report

[0430]FIG. 45 illustrates the Report Group Listing window, and FIG. 46illustrates a Report Group Listing Print Preview window.

Patients Module

[0431] In one embodiment, there are five basic functions to the Patientsmodule of the system:

[0432] Patient Records

[0433] Link Duplicate Patient Records

[0434] Reconcile Duplicate Patient Records

[0435] Patient Group Listing

[0436] Manage Patient Groups

[0437] These functions may be accessed through the Patients drop-downmenu, as shown in FIG. 47, or the Patients desktop menu. The Patientsfunctions pertain to managing patient records. The Patients functionsare described below.

Patients: Patient Records

[0438] The Patient Records menu option of the Patients menu allows theuser to:

[0439] Create new patient records

[0440] Find existing patient records

[0441] View details of existing patient records

[0442] Modify details of existing patient records

[0443] Print existing patient records

[0444] Each patient record may include the following types ofinformation:

[0445] Demographics information, such as:

[0446] Account#

[0447] Patient's Name

[0448] Home address

[0449] Home, work, and fax phone numbers

[0450] General identification, such as Social Security Number anddriver's license number

[0451] Birth date, birth place, and death date

[0452] General profile information such as sex, marital status, andethnic group

[0453] Religious information including religion, place of worship andreligious contact

[0454] Name Aliases (other names by which the patient has been or isknown)

[0455] Identifier information. The system allows the user to link to asingle patient record multiple identifiers that the user's organizationand other organizations use to track the patient record, such as chartnumber, record number, test number and account number. For example, onefacility may use Medical Record Numbers (MRNs) to keep track of itspatients while another facility may use Patient Identification Numbers(PIDs) for the same purpose.

[0456] Employment information, both past and present, including employername, address, phone numbers, employment period and position.

[0457] Guarantor information, which lists the person(s) responsible forany medical procedures not covered by a payer or a third party. Aguarantor can be any of the following:

[0458] the patient

[0459] a parent

[0460] the patient's spouse

[0461] the patient's employer

[0462] any other person financially responsible for the patient'smedical expenses

[0463] Medical Data, which the user's office and other organizationsmaintain for a patient.

[0464] Insurance information, which includes insurance code, payer,insured name, policy/member number, and effective dates.

[0465] Documents, which is a list of all documents, such as X-rays, labreports, and medical notes, etc., that have been added to the patient'sfile either through the user's organization or other organizations.

[0466] Contacts, which is a list of all persons who are contacts for thepatient and includes the person's name, address, phone numbers andrelationship to the patient.

[0467] Consent information, which indicates if there is a valid patientconsent form on file for a particular patient record.

[0468] Orders, which lists all laboratory tests performed on a patient.

[0469] Result Reports, which lists the results of all laboratory testsperformed on a patient.

[0470] Diagnosis Codes, which includes a patient's diagnosis codes andtheir description.

[0471] Patient information is used by many other modules in the systemand is shared within the user's organization as well as otherorganizations participating in the care of the patient. Therefore, greatcare should be taken to maintain the accuracy and integrity of thisinformation. The system includes various features for helping tomaintain data integrity, as described below.

[0472] Assuming the user has the proper security clearance, the PatientRecords function of the system allows the user to carry out thefollowing within each patient record:

[0473] Enter and modify demographic information in a patient record

[0474] Add, modify and remove name aliases in a patient record

[0475] Add, modify and remove identifiers in a patient record

[0476] Add, modify and remove employment records in a patient record

[0477] Add, modify and remove guarantor information in a patient record

[0478] Add, modify and remove medical data in a patient record

[0479] Add, modify and remove insurance information in a patient record

[0480] View, link and forward documents linked to a patient record

[0481] Add, modify and remove contacts in a patient record

[0482] Add, modify and remove consent informat ion in a patient record

[0483] Add, modify and remove lab orders from a patient record

[0484] View and print lab result reports in a patient record

[0485] Add and remove diagnosis codes in a patient record

Finding Patient Records

[0486] Patient records may be looked up in various ways, including byname, by identifier, or by social security number. The user may alsoperform a “power search” to lookup patient records. FIG. 48 illustratesthe Finding a Patient basic search window. This window may appear afterselecting the Patient Records menu option from the Patients menu or inother contexts, such as in response to selecting Create StandardRequisition from the Orders menu.

[0487] In one embodiment, the system may be enabled to interface with aPractice Management System (PMS). If the user's system has a PMSinterface and the user searched by Patient Account identifier type, thesystem may search the PMS first. If a record is not located in theuser's PMS with the matching account identifier, the PMS Search dialogbox appears. The patient index maintained by the system may then besearched for a matching record.

[0488] After performing a search, the search results appear in theFinding a Patient window, as shown in FIG. 49. The patient record ofinterest may then be selected, and the appropriate window appears. Forexample, if the Finding a Patient window was opened through the CreateStandard Requisition or Create Future Requisition options of the Ordersmenu, the Requisition window appears with the General page active, asshown in FIG. 15. If the Finding a Patient window was opened through thePatient Records option of the Patient menu, the Patient Details windowopens with Chart Page 1 active, as shown in FIG. 50. FIG. 51 illustratesChart Page 2 of the Patient Details window.

[0489]FIG. 52 illustrates the Finding a Patient power search window,which may also be used to lookup patient records.

Working with Patient Records: Patient Name Aliases

[0490] The Name Aliases page of the Patient Details window (not shown)lists other names by which the patient has been or is known. This pagemay be used to view or enter new name aliases for the patient.

Working with Patient Records: Patient Identifiers

[0491] The Identifiers page of the Patient Details window (not shown)lists identifiers which have been associated with the patient and allowsthe user to associate new identifiers with the patient. The systemallows the user to link to a single patient record multiple identifiersthat the user's organization and other organizations use to track thepatient record, such as chart number, record number, test number andaccount number. For example, one facility may use Medical Record Numbers(MRNs) to keep track of its patients while another facility may usePatient Identification Numbers (PIDs) for the same purpose.

Working with Patient Records: Patient Employment Records

[0492] The Employment page of the Patient Details window (not shown)lists employment information for the patient, both past and present, andincludes employer name, address, phone numbers, employment period andposition. This page may be used to edit or enter new employmentinformation for the patient.

Working with Patient Records: Patient Guarantors

[0493] The Guarantors page of the Patient Details window (not shown)lists the person(s) responsible for payment for any medical proceduresnot covered by a payer or a third party. A guarantor can be the patient,a parent/guardian, the patient's spouse, the patient's employer, or anyother person financially responsible for the patient's medical expenses.This page may be used to edit or enter guarantor information for thepatient.

Working with Patient Records: Patient Medical Data

[0494] The Medical Data page of the Patient Details window (not shown)lists data which the user's office and other organizations maintain fora patient. This page may be used to edit or enter medical data for thepatient.

Working with Patient Records: Patient Insurance

[0495] The Insurance page of the Patient Details window (not shown)lists insurance information, both current and expired, for the patient,and includes insurance code, payer, insured name, policy/member numberand effective dates. This page may be used to edit or enter insuranceinformation for the patient.

Working with Patient Records: Patient Documents

[0496] The Documents page of the Patient Details window (not shown)lists all documents, such as X-rays, lab reports, and medical notes,that have been added to the patient's file either through the user'sorganization or other organizations. This page may be used to view thedocuments, change document links, or forward documents to differentusers.

Working with Patient Records: Patient Contacts

[0497] The Contacts page of the Patient Details window (not shown) listspersons who are contacts for the patient, and includes the contact'sname, address, phone numbers and relationship to the patient. This pagemay be used to edit or enter contact information for the patient.

Working with Patient Records: Patient Consent

[0498] The Consent page of the Patient Details window (not shown)indicates whether there is a valid patient consent form on file for aparticular patient record. This page may be used to edit or enterconsent information for the patient.

Working with Patient Records: Patient Orders

[0499] The Orders page of the Patient Details window (not shown) listsall laboratory requisitions that have been prepared for the patient. Tocreate a new standard requisition, the user can click Create New. TheRequisition window appears with the General page active and the patientinformation populating the fields. This page may also be used to editorder information for the patient.

Working with Patient Records: Patient Result Reports

[0500] The Result Reports page of the Patient Details window (not shown)lists all result reports which have been received for the patient.

Working with Patient Records: Patient Diagnosis Codes

[0501] The Diagnosis Codes page of the Patient Details window (notshown) lists diagnosis codes which have been associated with thepatient, either manually through this page or automatically when arequisition is created for the patient. This page may be used to edit orenter diagnosis code information for the patient.

Duplicate Patient Records and GMPI Overview

[0502] Because patient records are setup and maintained by multipleusers at multiple facilities in the Health Data Network, it is possiblethat a patient will have multiple patient records. This can createproblems when determining which record to maintain. Duplicate recordscan splinter clinical data and hinder access to patient information.

[0503] For this reason, the system implements a Global Master PatientIndex (GMPI). The GMPI can link multiple records together for the samepatient. Thus, the GMPI gathers patient information together under asingle umbrella. In the preferred embodiment, GMPI functionality withinthe system includes:

[0504] Locating patient records

[0505] Locating duplicate records for a selected patient

[0506] Printing a selected patient record with all its duplicate patientrecords

[0507] Reconciling potential duplicate patient records found whilesearching and retrieving a patient's record

[0508] Final reconciliation (certification) of suspected duplicatepatients records

[0509] Maintaining a persistent relationship between patient records inthe GMPI

[0510] Maintaining a reconciliation audit trail

Patients: Link Duplicate Patient Records

[0511] The Link Duplicate Patient Records menu option of the Patientsmenu enables the user to link two patient records that are suspected ofbeing duplicates of each other. When linking the records, one isdesignated as the lead record (also called a master record) and theother the trailer of the lead record. Once linked, if the user selectsthe trailing patient record, the lead patient record will be openedinstead. The dialog box shown in FIG. 53 appears in order to notify theuser that this has occurred.

[0512] The link established between the two records using the LinkDuplicate Patient Records menu option may be referred to as a confirmedlink. This confirmed link may then be certified, e.g., by a GMPIadministrator.

[0513] When the user selects the Link Duplicate Patient Records menuoption, the Create Link Between Patients window appears, as shown inFIG. 54. In the Patient A field, the user selects the first patient ofthe duplicate pair. In the Patient B field, the user selects the secondpatient of the duplicate pair. If the user wants Patient A to be thelead record, the user clicks Confirm B into A. If the user wants PatientB to be the master record of Patient A, the user clicks Confirm A intoB. The Confirm Link Dialog Box then appears, as shown in FIG. 55. Theuser clicks Yes to confirm the link as described in the dialog box. Aconfirmed (directional) link between the records is then created, andthe Created a Link dialog box appears.

[0514] An unresolved link occurs when a user is reconciling a duplicatepair through the Link Duplicate Patient Records and selects the “I donot know option”. In this case, the link status changes from anunconfirmed link to an unconfirmed unresolved link. This link status isnot visible to the user, but it will appear in the Suspected DuplicateLog under the Unconfirmed Link column. If the user selects a patientrecord with an unresolved link during the reconciliation process, thefirst column of the reconciliation grid on the LINK row will display theunresolved link status. If the link has been reconciled with the “I donot know” option meaning it is an unresolved link, the user line willdisplay the name of the user who carried out the reconciliation action.Unresolved links do not appear displayed on any of the applicationscreens, but the GMPI system keeps track of them in an audit trail logthat can be viewed or printed by administrators.

Patients: Reconcile Duplicate Patient Records

[0515] The Reconcile Duplicate Patient Records menu option of thePatients menu is used to provide official certification of patientrecord links. This function is typically used by administrators who areresponsible for the oversight and maintenance of the Global MasterPatient Index (GMPI).

[0516] When the user selects the Reconcile Duplicate Patient Recordsmenu option, a list of patient records that have links to other recordsappears, as illustrated in the Finding a Patient with Links window (FIG.56). As shown in FIG. 56, the system provides filters enabling the userto filter the patient records that appear in the list. For example, thefilter may be based on the system time stamp: e.g., 24 hours, 48 hours,72 hours, 7 days, 30 days, etc. Also, a custom filter may be applied.For example, the custom filter may enable the user to search for patientrecords by link status, such as Unconfirmed Link, Indirect Link,Confirmed Link, Confirmed Unlink, Certified Link, and All.

[0517] The Certified Link column indicates the number of certified linksfor the patient. The Con firm ed Link column indicates the number of confirmed links for the patient. The Confirmed Unlink column indicates thenumber of confirmed unlinks (or denigrated links) for the patient. TheIndirect Link column indicates the number of indirect links for thepatient. The Unconfirmed Link column indicates the number of unconfirmedlinks for the patient.

[0518] Assuming the user has the proper security clearance, theReconcile Duplicate Patient Records function of the system enables theuser to:

[0519] Retrieve and View the selected patient record and all itspotential duplicates. The selected patient's demographics along with allits links appear in columnar format.

[0520] View a graphical representation of the selected patient recordand all its potential duplicates.

[0521] Print demographics information for the selected patient recordand its suspected duplicate records.

[0522] View details of the selected patient record or any of itsduplicate records on the grid.

[0523] Reconcile a link between duplicate patient records. Reconciling aduplicate record pair involves one or more of the following tasks:

[0524] Denigrating a link between two records.

[0525] Certifying a confirmed or unconfirmed link. This creates acertified link between two records.

[0526] Certifying a denigrated link

[0527] Denigrating a certified or confirmed link. When a certified orconfirmed link is denigrated, it ceases to be directional.

[0528] Examine the Link Path of any potential duplicate records. Thismeans that the user can select one of the duplicate records and make itthe new selected patient record to view all of its links.

[0529] To find a patient record with links, the user chooses ReconcileDuplicate Patient Records from the Patients menu. The Finding a Patientwith Links window appears, as shown in FIG. 56. The user may select apre-defined filter from the drop-down list next to the Filter field. Theuser may apply a custom filter by clicking Custom. The Custom Filterwindow appears, as shown in FIG. 57. The user may then enter the filtercriteria in the fields and click Apply to apply the filter and return tothe Finding a Patient with Links window.

[0530] The result list appears, as shown in FIG. 56. To sort the list,the user can move the mouse pointer over the heading of the column tosort on and click. The search results list is sorted in ascending orderusing the selected column as the sort criteria.

[0531] To print the list, the user clicks Print List. FIG. 58illustrates a Print Preview window.

[0532] To reconcile a patient record, the user highlights the desiredrecord and clicks Continue. The Finding a Patient with Links tableappears, as shown in FIG. 59. To reconcile duplicate patient records,the user highlights a Duplicate patient record to reconcile with theselected patient record and clicks Reconcile.

[0533] In response, the Reconcile Patient Duplicate dialog box appears,as shown in FIG. 60. The dialog box includes a statement at the topindicating which patient record is currently designated as the PotentialDuplicate and which patient record is designated as the SelectedPatient.

[0534] To make the Selected Patient the leader record of the PotentialDuplicate, the user chooses “Yes. Make Selected Patient the new Masterrecord”.

[0535] To make the Potential Duplicate the leader record of the SelectedPatient, the user chooses “Yes. Make Duplicate # the new Master record”.

[0536] If the records are not duplicates, the user chooses “No. they arenot duplicates”.

[0537] To certify the association between the Selected Patient and thePotential Duplicate, the use chooses “Certify the association betweenthe Selected Patient and the Duplicate #.”

[0538] To denigrate the association between the Selected Patient and thePotential Duplicate, the user chooses “Dissolve the association betweenthe Selected Patient and the Duplicate #”.

[0539] To terminate reconciling the two patient records, the user clicksCancel.

[0540] To view the details of a patient, the user highlights the columncontaining the patient to view and clicks View Details. The PatientDetails window appears.

[0541] To show the identifiers for each patient, the user clicks ShowIdentifiers. The list “jumps” to the fields containing the identifiersfor the patients.

[0542] To view a graphical representation of the table, the user clicksGraphical. In response, a graphical representation window appears, asshown in FIG. 61. The user can click and drag a patient-bubble acrossthis window. To view details of the patient record, the user candouble-click on a patient-bubble and select View Details from the menuthat appears. To reconcile a patient record, the user can double-clickon a patient-bubble and select Reconcile from the menu that appears. Toreturn to the Finding a Patient with Links table window, the user clicksBack. To print the Finding a Patient with Links table window, the userclicks Print.

Patients: Manage Patient Groups

[0543] The Manage Patient Groups menu option enables the user to createpatient categories that are identified by a code and to sort patientsinto these various categories. Examples of patient groups are “High HDLCholesterol Group”, “Diabetes Control Group”, and “E. Coli Testing”.Patient Groups with Report Groups are used to generate Results SummaryReports and Cumulative Reports. Information obtained from these reportscan be used to schedule patient visits in advance, gather valuablestatistical information and identify trends in a patient population.

[0544] When the user choose Manage Patient Groups from the Patientsmenu, the Patient Group Management window appears, as shown in FIG. 62.From the Manage Patient Groups menu option the user can:

[0545] List all patient groups

[0546] List all the patients in a patient group

[0547] Create New patient groups

[0548] Add a new patient to a patient group

[0549] View a patient group

[0550] View details of each patient in a patient group

[0551] Modify details in a patient group

[0552] Remove a patient group

[0553] Remove a patient from a patient group

[0554] Print a list of all the patient groups

[0555] Print details on a specific patient group

[0556] The user can follow the following procedures to view or modify anexisting patient group from the Patient Groups Management window.

[0557] 1. On the Patient Groups Management, highlight the patient groupto view or modify and click Details. The Patient Group Details windowappears for the selected patient group, as shown in FIG. 63. TheDescription field is a description of the patient group. The PatientGroup Code field is the patient group code. The Provider field is theprovider for which the patient group was created. The default value forthis field is the active HDN Business.

[0558] 2. View or modify the fields at the top of the screen.

[0559] 3. Add and/or remove patients on the Patients included in thisGroup list. To add a patient to the group, click Find. The Finding aPatient window appears. Find an existing patient or create a new patientto add to the patient group. The patient is added to the group. To getdetails of a patient previously added to the group, highlight thepatient and click Details. The Patient Details window appears with theChart Page 1 page active and the information last entered for thepatient populating the fields.

Patients: Patient Group Listing

[0560] The Patient Group Listing menu option of the Patients menuenables the user to preview or print a list of all the patient groupsfor each provider that are created through the Manage Patient Groupsfunction. The items on the list appear sorted in alphabetical order. Aheader page is a configurable option. The header pages shows: Date andtime of the report, Name of the user running the report, Comment line,and Search criteria used to generate the report.

[0561] To generate the Patient Group Listing, the user selects PatientGroup Listing from the Patients menu. The Patient Group Listing windowappears, as shown in FIG. 64. The user then enters criteria forgenerating a patient group listing. FIG. 65 illustrates a Patient GroupListing Print Preview window for previewing a report.

User Module

[0562] In one embodiment, there are four basic functions to the Usermodule of The system:

[0563] Change Active HDN Business

[0564] Change Password

[0565] Manage Preferred Lists

[0566] View Documents

[0567] These functions are accessed through the User menu, as shown inFIG. 66, or the User desktop menu. The User functions are describedbelow. Before discussing these functions, a brief overview of securityconsiderations is given.

Security Considerations in The system

[0568] The system provides the ability to secure information across alarge and open network of computers and the people that use them. Thisnetwork is referred to herein as a Health Data Network, or HDN. Thesecurity of this network, including access to it, is critical becausethe system provides access to confidential patient information,including laboratory test results and medical history.

[0569] User Accounts—Before the user can log on to the system, the usermust have a user account including a logon name and a password. The useraccount provides the needed security for controlling access to the HDNand identifies the user while the user is using the system.

[0570] HDN Businesses—When the user log on to the system, the userconnects to the system on behalf of a Health Data Network (HDN)Business. An HDN Business is any business, including a hospital, clinic,physician office, laboratory, payer, or employer, that participates inthe creation and sponsorship of a specific HDN.

[0571] Through the user's user account, the user is linked with HDNBusinesses. The user may be allowed to log on to the system on behalf ofmore than one HDN Business. For example, the user's primary HDN Businessmay be the office in which the user is currently working, but there mayalso be times when the user may need to access the system on behalf of ahospital where the user has patients in order to check on their status.In this case, the user may be linked to both HDN Businesses, the user'soffice and the hospital.

[0572] Parent-Child HDN Businesses—If the user's practice has more thanone location or business unit, and all orders and results are sharedthroughout the practice, the user's practice may be configured as asingle HDN Business. In this case, the practice's data may be stored ina central location and can be accessed by all users who have theappropriate permissions.

[0573] However, if the user's practice has more than one location orbusiness unit, and the need exists to keep orders and results isolatedwithin a location or business unit, the practice may be configured in aparent-child HDN Business relationship. This prevents lab orders andresults and other data associated with one location or business unitfrom being accessed by users logged on to other locations or businessunits of the practice.

[0574] 1. A parent HDN Business is created for the entire practice.

[0575] 2. Child HDN Businesses are created for each business unit orlocation. Some business units or locations may actually share a singlechild, while others may be set up as individual child HDN Businesses.

[0576] 3. All child HDN Businesses are linked to the single parent HDNBusiness.

[0577] 4. The user's user account is associated with each child HDNBusiness where the user are permitted to access the information. Theuser's account may not be associated with all child HDN Businesses forthe practice. Some advanced users may have their account associated withthe parent HDN Business so they can carry out global administrativefunctions.

[0578] The data for the user's practice is then stored at two levels:

[0579] 1. At the parent-level, the following information is stored andavailable to all child HDN Businesses of that parent HDN Business:

[0580] Patient records and supporting information, excluding orders andresults

[0581] Payers

[0582] Providers and caregivers

[0583] Codes, including diagnosis codes (ICD-9), test codes, analytecodes, report codes and profile codes

[0584] Report groups, patient groups and test groups

[0585] System configuration

[0586] When the user add any of these items to the system, they areavailable to all child HDN Businesses associated with the parent HDNBusiness.

[0587] 2. At the child-level, the following information is stored onbehalf of and is only available to users logged on to that child HDNBusiness: p1 User preferences

[0588] Orders

[0589] Results originating from orders transmitted on behalf of thechild HDN

[0590] Business

[0591] The orders, results and user preferences for each child HDNBusiness are isolated from the other child HDN Businesses. The only waya user can access this information is to log on to the child HDNBusiness. If the user are logged on to the parent HDN Business and havethe appropriate permissions, the user can access all information for thepractice, including the orders and results stored specifically for achild HDN Business.

[0592] Healtheon Field Service Representatives work with the user'spractice to best determine the configuration of the user's system fromthe perspectives of data management and security.

Permissions, Roles, Operations and Objects

[0593] In addition to the ability to log on to the system on behalf ofan HDN Business, users also must have permission to actually use themany functions of the system, and need access to the data stored acrossthe HDN. As part of creating the user's permission profile, the user isassigned a role that the user performs when working with the system.This includes information regarding the types of data the user needs tobe able to access and the functions the user needs to carry out on thatdata.

[0594] Types of data are referred to as objects and functions arereferred to as operations. Patient records, lab requisitions, labresults, test codes, ICD-9 codes, lab profiles and physician profilesare examples of objects. An example of an operation is adding newobjects. Viewing, modifying, printing, and deleting existing objects arealso examples of operations. The process of searching for existingobjects is also considered an operation.

[0595] A role defines what objects a user can access and what operationsa user is allowed to carry out on each of those objects. For example,one role may allow users to add, view, modify, print and delete lab testrequisitions, while another role may only allow users to view and printlab test requisitions.

[0596] When a permission profile is defined for the user, it is specificfor an HDN Business. If the user belongs to more than one HDN Business,the user may have more than one permission profile. Each of theseprofiles may be different. For example, the user may have permission toadd, view, modify, print, and delete patient records on behalf of oneHDN Business, but the user may only have permission to view and printpatient records on behalf of another HDN Business.

[0597] Effective dates and expiration dates may also be set for eachpermission profile, creating a limited period of time when thatpermission profile is in effect. This can be useful, for example, if afirst user is going to be temporarily out of the office and the firstuser needs to be able to allow a second user to do the first user's workwhile the first user is gone. The permission profile for the second usercan be set to begin the first day the first user is out of the officeand to expire at the end of the day before the first user returns.

[0598] An administrator may work with users to ensure that thepermission profiles and roles selected for each user are sufficient tomeet the users'job requirements.

User: Change Active HDN Business

[0599] When the user logs on to the system, the user is connected to theHDN on behalf of an HDN Business. The user may select a default HDNBusiness at login time. For example, after entering a username andpassword, a popup window may appear with a list of HDN Businesses tochoose from. Once the user log on to the system, a message at the bottomof the screen displays the name of the user's current HDN Business.

[0600] The Change Active HDN Business menu option of the User menuenables the user to select another HDN Business after the user haslogged on to the system, provided that the user has permission to accessmore than one HDN Business. This permission may be set up by anadministrator. When the user chooses the Change Active HDN Business menuoption, the Change HDN Business dialog box appears, as shown in FIG. 67.The list includes HDN Businesses with which the user is associated butthat are not currently active. After switching to another HDN Business,the switch can be confirmed by checking the status bar, as shown in FIG.68.

User: Change Password

[0601] The Change Password menu option of the User menu enables the userto change the user's account password. The Change Password dialog boxmay impose different criteria for determining whether a password is avalid password, depending on how an organization has configured thisfunction.

User: Manage Preferred Lists

[0602] Preferred lists are a time saving feature that enable the user tocarry out repetitive tasks more efficiently. The Manage Preferred Listsmenu option of the User menu provides a means to carry out variousrecurrent tasks quickly without having to go through multiple screensand numerous keystrokes. In one embodiment, the system enables the userto set the user's own preferences for:

[0603] Caregivers

[0604] IDN Businesses

[0605] Payers

[0606] ICD Diagnosis Codes

[0607] ICD Procedure Codes

[0608] CPT Codes and

[0609] Test Codes

[0610] The system enables the user to maintain and modify thesepreference lists to suit the user's own requirements. Setting uppreference lists helps the user streamline many tasks the user doeswithin the application. The following is a sample of some commonrepetitious tasks that the user can be simplified by using preferredlists:

[0611] Creating Requisitions

[0612] Generating Lab Reports

[0613] Entering Insurance Information for a Patient

[0614] In the Preferred List Manager window, shown in FIG. 69, twoseparate lists appear side by side. On the left side of the screen,there is a list of Available items. On the right side of the screen,there is a list of Preferred items. New entries can be added to bothlists.

[0615] From the Manage Preferred Lists menu option the user can:

[0616] Retrieve a preferred list.

[0617] Add items to a preferred list

[0618] Modify items on the user's preferred list

[0619] Remove single or multiple items from the user's preferred lists

[0620] Apply a Custom Filter to narrow down the user's search results

[0621] Get Details on any preferred list item

[0622] Print a preferred list

[0623] Shared Lists—The user can view the preferences of another user atthe user's HDN Business or at another HDN Business and use items fromtheir existing preferred lists to create the user's own list. There aretwo types of preferences: shared and individual. For example, in thecase of caregivers, the user can have a My Caregivers preferred list anda Shared Caregivers preferred list.

[0624] Under the My Caregivers preferred list, a user may include thosecaregivers that only that user uses on a regular basis. Under the SharedCaregivers preferred list, the user may include those caregivers thatare accessed by that user as well as other users associated with theactive HDN Business. The user can have two types of preferred lists forother categories as well (HDN Businesses, Payers, ICD, CPT and TestCodes, etc).

[0625] Each HDN Business can set up its own list of preferences and makethis list accessible to all users at that HDN Business. A user can havea different preferred list of items for every HDN Business the user hasaccess to.

[0626] When the user displays a preferred list, the shared andindividual lists may be combined and sorted in various ways, dependingon what type of data the lists contain. For example, lists ofcaregivers, HDN Businesses, and payers maybe sorted in alphabeticalorder, whereas lists of ICD, CPT and test codes may be sortednumerically by code. Each item on a list may also have a descriptivecomment next to it.

[0627] Users may own their preferred lists so that the entries a usermakes to the user's preferred lists can be deleted only by that user.The HDN Business user preferences are accessible to all the users atthat HDN Business. In one embodiment, they can be modified or deleted byany user at the HDN Business. Preferences may be linked to the user'saccount rather than to the user's workstation. Thus, the user can viewthe same preference lists regardless of the workstation used to accessthe system.

User: View Documents

[0628] An HDN business typically sends, receives, and stores manyreports and other documents. Although these documents are oftengenerated electronically by the various participants in the delivery ofhealthcare services for a patient, including health care providers,hospitals, labs and payers, the documents are traditionally printed anddistributed by a number of different manual delivery methods, such asinteroffice mail, facsimile, US Mail, or some other physical deliverymethod.

[0629] The View Documents menu option of the User menu provides instant,two-way, electronic communication between the various participants inthe delivery of healthcare services for a patient. Documents, such asthose described previously, can be linked to a user or list of users andthen listed on their User Document List, shown in FIG. 70. From theuser's User Document List, the user can:

[0630] View the document

[0631] Link the document to a patient record

[0632] Forward the document to another user or group of users

[0633] Documents that are not generated electronically or are from asource not participating in the Health Data Network (HDN), such as anemployer, can be faxed into the user's system and then linked to a useror list of users. The faxed document is then treated like any otherdocument generated electronically within the HDN.

[0634] The following table provides definitions for the columns on theUser Document List window: Column Description Category The documentcategory Date Created The date the document was created Document SourceThe source of the document Document Type The type of document From Theuser who forwarded the document to the user Linked To The person to whomthe document is linked Status The read status of the document. A “U”indicates that the document is unread Urgent An exclamation point (“!”)indicates an urgent document

[0635]FIG. 71 illustrates a window for applying a custom filter to theUser Document List.

[0636]FIG. 72 illustrates a window for viewing a user document.

[0637]FIG. 73 illustrates a window for editing the link for a userdocument.

[0638]FIG. 74 illustrates a window for forwarding a user document to oneor more users.

Admin Module

[0639] Tasks carried out in the application comprise administrative aswell as user tasks. Administrative tasks are found on the Admin menu, asshown in FIG. 75, which includes a Site Configuration option and thefollowing five submenus:

[0640] Manage Businesses

[0641] Manage Security

[0642] Manage Health Care Codes

[0643] Manage Resources

[0644] Manage System Integration

[0645] It is noted that some or all of the functions accessible via theAdmin menu may be restricted for use only by users with administrativeprivileges. Thus, in the following descriptions of the Admin menuoptions and submenus, the term “the user” may refer to administrativeusers.

Admin: Site Configuration

[0646] Before using the Admin menu options to configure the user's site,it is important to have an understanding of Health Data Network (HDN)Businesses, and how they relate to other system components. The usermust also understand the concept of parent-child relationships in orderto successfully maintain the user's site.

[0647] In the preferred embodiment, the system can interface to multiplelabs simultaneously and seamlessly. The Site Configuration option in theAdmin menu enables the user, e.g., an administrator, to support andmanage this feature and provides the user the functionality needed todefine relationships between the user's site and several laboratories.

[0648] When selected, the Site Configuration window appears with theGeneral page active, as shown in FIG. 76. This page is used to specifyHDN Business level interface settings that affect how the system works.

[0649] The Lab page, shown in FIG. 77, is used to define and maintaininformation on provider-lab associations. Before an order can be sentfrom a Provider HDN Business, that business must have at least one labassociation and one client ID for that association. From this page, theuser can carry out the following functions:

[0650] Create, configure and maintain associations between a providerand multiple labs

[0651] View and/or modify detailed lab information

[0652] Create Client IDs for each provider-lab association

[0653] View and/or modify information on existing Client IDs

[0654] Print configuration data, lab association information and ClientIDs for a provider

Site Configuration—General Page

[0655] As described above, a user's practice may be configured as aparent-child HDN Business relationship. To modify the configuration dataof the table shown in FIG. 76, the user may log in to the parent HDNBusiness. A message appears at the top of the page in FIG. 76 indicatingthe name of the HDN Business the user is currently viewing.

[0656] When the user views a child HDN Business, the configuration datathat appears on the screen may be that of the parent HDN Business. Inone embodiment, any configuration data defined at the parent levelcannot be modified at the child level. When viewing information for achild business, any parent-specific data may appear grayed out on theconfiguration table so that the data cannot be modified. As describedabove, individual HDN Businesses may have their own policies regardingwhat permissions a user can have. Thus, a Business may define a policysuch that only administrators are allowed to define or modifyconfiguration information.

[0657] The following table explains the fields on the General page ofthe Site Configuration Details window: Field Name Definition AccountPath for PMS The account path for a Practice Management Interface System(PMS) interface. Baud rate for PMS The baud rate for the PMS interface.Interface Client Type The client type. Databits for PMS The number ofdatabits for the PMS interface. Interface Default Bill Type The defaultbill type. Includes drop-down list values of: Client, Patient or ThirdParty. The value selected appears as the default Bill Type when creatinga requisition. Interface for the PMS The interface for the PMS system.System Months before results The number of months before results areready to be archived. Parity for PMS The parity for the PMS interface.Interface Patient Label Barcode Indicates the method used for encodinginfor- Format mation in the patient label bar code. PMS Check RequiredThis box tells the system to search for patient records in the PracticeManagement System Port for PMS Interface The port for the PMS interface.Print Patient Label Indicates whether patient labels are printed. Ifthis box is selected, a label is printed when a requisi- tion iscreated, as long as a label printer is attached to the workstation wherethe requisition is created. Labels are placed on specimens foridentification purposes. Refresh Results The frequency at which theresults statistics in the Statistics Frequency main screen status barare updated. (Not Viewed (hours) Results, Abnormal Results) Single UserSite Indicates if the site is a single user site. Stopbits for PMS Thenumber of stopbits for the PMS interface. Interface

Site Configuration—Lab Page (FIG. 77)

[0658] Providers can preferably send orders through either parent orchild labs, as long as they are orderable labs. Orderable labs are thosethat a client can directly send orders to. For every set of labsassociated with a provider, one of the labs may be setup as the defaultlab. Each Provider HDN Business may have a set of Labs associated withthe Provider and a set of Client IDs linked to the Provider. The Labpage of the Site Configuration window, shown in FIG. 77, includesfunctions for managing this information.

[0659] The Laboratory Associations portion of the Site ConfigurationDetails window allows the user to define and maintain associationsbetween the user's site and various labs. These lab associations must bedefined before a Provider HDN Business can send orders to one or morelabs. The associations between a Provider HDN Business and a set oforderable labs may be defined at the parent level, and child HDNBusinesses may inherit the lab associations of their parent HDNBusinesses.

[0660] The management and creation of lab detail information may beperformed through the Labs subsystem of the Manage Businesses submenuoption, as described below. The user can also view and modify lab detailinformation on labs accessed through the Site Configuration Detailswindow. In the Laboratory Associations section of the Lab page the usercarry out the following functions:

[0661] Create and configure associations between a site and one or morelabs

[0662] View and/or modify detailed information on existing labs

[0663] Print lab association information

[0664] To configure a provider-lab association, the user highlights theprovider-lab association to configure and clicks Configure. In response,the Lab Association Configuration window appears, as shown in FIG. 78.The user may then modify the fields on the page as needed. The followingtable explains the fields found on the Lab Association Configurationwindow: Field Name Definition Allow manual If this box is selected,manual requisition numbers requisition numbers can be entered whencreating a requisition. Otherwise, each new requisition uses a numbergenerated by the system. Eligibility results This field appliesprimarily to Future requisitions. If rechecked after eligibility hasbeen verified for a requisition, patient delay of (hours) or insurancewithin the specified number of hours, it will not be re-checked.Otherwise, it will be verified again. Exclude Bill Type A drop-down listwith possible values of Client, Patient or Third Party. If a value isselected then that Bill Type cannot be used when creating a requisition.FDA check required When this box is selected, if Bill Type is ThirdParty and the patient has a limited coverage policy, such as Medicare,and a non FDA-compliant test code is used in a requisition, the ABNDialog box appears. An Advanced Beneficiary Notice (ABN) is a printedstatement that includes a list of tests not covered by the payer. HDNBusiness The Provider IHDN Business being linked to a lab. Also, thecurrently active HDN Business. This is a read only field and cannot bemodified. Lab The Lab associated with the Provider. This is a read onlyfield and cannot be modified. LCP check required When this box isselected, if Bill Type is Third Party and the patient has a limitedcoverage policy, such as Medicare, and a non LCP-compliant test code isused in a requisition, the ABN Dialog box appears. An AdvancedBeneficiary Notice (ABN) is a printed statement that includes a list oftests not covered by the payer. Maximum This field is used to designatethe maximum requisition requisition number that can be entered,regardless of number whether manual or automatic requisition numbers areused. Minimum This field is used to designate the minimum requisitionrequisition number that can be entered, regardless of number whethermanual or automatic requisition numbers are used. Selec Test OnlyAccepts one of two possible values, Yes or No. Specificity check Whenthis box is selected, if a user enters an ICD-9 required code in arequisition that has more specific designations or codes, the user isrequired to select a more specific ICD-9 code instead of the non-specific one. Transfer ID A unique identifier assigned to each site.This field is used during the process of uploading and downloadingresults. Multiple client IDs may map to the same transfer ID.

[0665] It is noted that for every set of labs associated with aprovider, one lab may be selected as the default lab. The defaultlaboratory may be used for requisitions that have patient or clientbilling. However, when creating a requisition, a user can send the orderto any lab associated with the provider HDN Business, even if anotherlab has been defined as the default lab.

[0666] The Client IDs portion of the Site Configuration Details windowallows the user to create and maintain client ID information for theuser's site. Client IDs are used for billing and for distributing labresults. Providers must have Client IDs in order for them to be able tosend orders to a lab. In addition to the default client ID for theuser's site, the user can also have numerous client IDs associated todifferent caregivers and to the user's site. For businesses that have aparent-child relationship, the workstation client IDs may be linked tochild HDN Businesses so that the results ordered can be returned to theoriginating workstations. To support the proper distribution of resultsbased on client ID, client IDs can be stored at the parent or at thechild HDN Business level. For every set of client IDs associated with aprovider, one ID may be selected as the default client ID.

[0667] In the Client IDs section of the Lab page the user can performthe following functions:

[0668] Create Client IDs for each provider-lab association

[0669] View and/or modify information on existing Client IDs

[0670] Print information on Client IDs

[0671]FIG. 79 illustrates a window for creating or editing aProvider-Lab Client ID. The following table explains the fields found onthe Provider-Lab Client ID Details window: Field Name DefinitionCaregiver This is the name of the physician to whom the provider clientID is assigned. If no physician is selected, the client ID is definedfor the provider. Client ID The lab assigned identifier for theprovider. Default Client ID This check box indicates if the client ID isthe default ID for the provider. Description A description of theassociated provider caregiver. Lab The lab associated with the provider.This field cannot be modified. Provider The name of the provider to whomthe client ID is assigned. This field cannot be modified.

Admin: Manage Businesses

[0672] In a health care delivery system, businesses rarely function asstandalone units. Because of the layered business structures that existin today's health care industry, flexibility is needed to define andmanage business units. With the Manage Businesses submenu, the user hasthe flexibility to manage various types of businesses. These businesstypes may include the following: Business Type Definition Employers Acompany that the patient, insured party, or guarantor works for. Labs Anorganization that provides clinical testing and observation. Payers Aparty responsible for paying the lab bill, usually a commercial healthinsurer or government agency that underwrites or administers programsthat pay for health services. Providers An institution or individualthat gives medical care.

[0673] Business subsystems for managing these business types may beaccessed through the Manage Businesses option of the Admin menu, asshown in FIG. 80.

Admin: Manage Businesses: Employers

[0674] Although the employers of patients, insured parties, andguarantors are not directly involved in the delivery of healthcare, theyare part of the business structure. Using the Employer menu option ofthe Manage Businesses submenu, the user can carry out the followingfunctions:

[0675] Create new employer records

[0676] View and/or modify existing employer records

[0677] Print employer records details

[0678] Delete employer records

[0679] Print lists of employers

[0680] Once created, employer records can then be linked to patient,insured party and guarantor records.

Admin: Manage Businesses: Labs

[0681] A lab may be an organization that provides clinical testingand/or observation services. Using the Labs menu option of the ManageBusinesses submenu, the user maintains information on the labs the userdoes business with. This information may be used by functions accessedvia the Orders menu, which include utilities used to prepare and submitrequisitions. In the Labs subsystem, the user can carry out thefollowing functions:

[0682] Create new lab records

[0683] View and/or modify existing lab records

[0684] Print lab records details

[0685] Delete lab records

[0686] Print lists of labs

[0687] In addition to basic demographic information, each lab record mayinclude information shown in the following table: Information TypeDefinition Child Labs These are the children of a parent lab. Not alllabs have child labs. Configuration These are the configuration settingsfor the lab. Payers These are the payers associated with the lab thathave electronic eligibility.

[0688]FIG. 81 illustrates the Lab Details window, for creating a new labor modifying details of an existing lab. The following table explainsthe fields found on the Lab Details window: Field Name DefinitionAddress The lab address. Alt. Name An alternative name that identifiesthe lab. City The city for the lab mailing address. Director's Name Thename of the lab director. Federal Tax ID The lab Federal TaxIdentification number. Lab Code A user-defined identifying code for thelab. Name The complete name of the lab. Orderable If this box isselected the lab is an orderable lab. An orderable lab is one that aclient can directly send orders to regardless of how a Provider HDNBusiness is setup. Parent lab If the lab is a child, this field containsthe name of the parent lab. Phone The phone number of the primarycontact at the lab. Sec. Dir. Name: An alternate contact for the labdirector. State The 2-character abbreviation for the name of the Statein the lab mailing address. Transmission mode The transmission mode usedby the lab. In general, sponsoring labs use electronic transmission,while generic labs use manual or paper based transmission. Zip The zipcode for the lab address.

[0689] To access the Configuration page, the user clicks Configurationon the Lab Details window. In response, the Configuration Details windowappears, as shown in FIG. 82. The Configuration Details window enablesthe user to define lab level settings for a specific lab. These settingsmay affect how some of the data is stored in the system, as well as theprocess of creating requisitions and the use of lab records. They alsoaffect the relationship between labs and payers. From this page the usercan define the level of data ownership for a lab: parent only, childonly, or a combination of both. This page enables the user to specifywhat data is stored at the parent level and what data is stored at thechild level.

[0690] The following table explains the fields found on theConfiguration page of the Lab Details window. Note that a Parent? checkbox appears next to every configuration field. This box indicates thelevel of ownership, parent or child, for each field. If the Parent? boxis checked, this means the setting is defined at the parent level andthe children of that lab will inherit that value. The field appearsgrayed out or disabled when viewed from a child lab. If the Parent? boxis unchecked, this means the setting is deferred to the children of thatlab. The field is enabled when viewed from a child lab. Field NameDefinition Default Billing The default Host System Identifier for aPayer. Mnemonic Max diagnoses per The maximum number of diagnosis(ICD-9) codes test allowed per test. Max tests per The maximum number oftest codes allowed in a requisition requisition. Max copy to per Themaximum number of Caregivers to receive requisition copies of arequisition. This field affects the list of caregivers in the AdditionalInfo page of a requisition. Copy to electronic This check box affectsthe physician results list in only? the Additional Info page of arequisition. If this box is checked, the search only returns caregiversthat have Client IDs. Otherwise, the search returns all caregivers thatmeet the user's search criteria. Print Specimen This check boxdetermines whether a specimen bar Barcode code is printed when arequisition is created. Specimen Barcode Defines the method used forencoding information Format in a bar code. A value may be selected fromthe drop-down list. Requisition Report Defines the requisition reportformat. A value may Format be selected from the drop-down list. SingleResult Report The format of a typical result report. A value may Formatbe selected from the drop-down list. Logo Filename/Path This is the filename and location of the logo image that appears on a requisition.Transfer ID Format Specifies the transfer ID format. (X means anyalphanumeric character is allowed, N stands for numeric, A stands foralpha, and anything inside quotes is a literal string or code). ClientID Format Specifies the Client ID format. (X means any alphanumericcharacter is allowed, N stands for numeric, A stands for alpha, and anytext inside quotes is a literal string or code). Billing MnemonicSpecifies the Billing Mnemonic format. (X means format any alphanumericcharacter is allowed, N stands for numeric, A stands for alpha, and anytext inside quotes is a literal string or code). Eligibility CheckingThe eligibility checking mode for the lab. This field may have a valueof Always OFF, Always ON, or ON by Payer. (See below.) TransactionRouting The lab Transaction Routing Method. This field Method affectselectronic transmissions. For generic labs, the field can be left blank.

[0691] Eligibility Checking—Some labs prefer to have eligibilitychecking or enabled for all payers, some labs want this feature disabledall the time, and other labs want to be able to select which payers toperform electronic eligibility checking on. The system may support thesedifferent scenarios by providing various settings for checkingeligibility. The user may specify these settings through the EligibilityChecking field which appears on the Configuration page of each lab.

[0692] In one embodiment, the user can set the Eligibility Checkingfield to be one of the following: OFF Always; ON Always; or ON by Payer.If the user selects the ON by Payer option, the user can select payersfrom an existing set of payers that have been globally enabled forelectronic eligibility within the system. Eligibility payer lists may bedefined at the same lab level (parent or child) that the EligibilityChecking configuration option is defined.

[0693] To access the Child Labs page, the user clicks Child Labs on theLab Details window. In response, the Child Labs window appears, as shownin FIG. 83. The Child Labs page lists the children of a parent lab. Thisrelationship is established when a Parent lab is selected for a childlab on the Lab page of the Lab Details window. When the user views aparent lab that has children labs, the Child Labs page is active and itincludes a list of all the children labs. When the user views a parentlab that has no children labs, the Child Labs page is active, but nolabs are listed.

[0694] From the Child Labs page, the user can carry out the followingtasks:

[0695] View details of existing child labs

[0696] Modify detail information of existing child labs

[0697] Modify the parent-child relationship between two labs

[0698] To access the Payers page, the user clicks Payers on the LabDetails window. In response, the Payers window appears, as shown in FIG.84. Payers can have contractual agreements with some labs, wherein ifthe lab work for a patient is sent to a contracted lab, there is afinancial benefit to be gained by the payer. The lab-payer associationsare typically defined at the parent lab level, but the system does notrestrict it to this level. The association between labs and payers ismanaged through the Payers page of the Lab Details window. The Payerspage includes a list of payers associated with a lab that may be checkedfor eligibility if electronic eligibility is enabled.

[0699] From this page, the user carry out the following tasks:

[0700] Associate existing payers with labs

[0701] View details of existing payers

[0702] Remove existing associations between payers and labs

Admin: Manage Businesses: Payers

[0703] A payer typically refers to an insurance company, but it can meanany organization, such as an employer or government agency, that paysfor medical services provided to a patient. A payer is different than aguarantor. The guarantor is the person ultimately responsible forpayment of the medical bill. For example, if the insurance company doesnot cover medical charges, the guarantor, which is usually the patientor the patient's guardian, is responsible for payment.

[0704] Using the Payers menu option of the Manage Businesses submenu,the user can carry out the following functions:

[0705] Create new payer records

[0706] View and/or modify existing payer records

[0707] Print payer records details

[0708] Delete payer records

[0709] Print lists of payers

[0710] In addition to basic demographic information, each payer recordmay include the following information: Information Type DefinitionProviders Providers and caregivers for whom the payer will cover medicalexpenses. Service Services on the network that the payer participatesin. Billing Lab-defined billing IDs for the payer. Insurance A userdefined value used to identify a payer. Code Labs The labs for whom thepayer will cover medical expenses.

[0711] Because the number of payers stored on the user's system may bevery large, the user can create a list of preferred payers as describedabove. The Preferred List of Payers may include those payers that theuser frequently uses, which makes locating a payer much easier andfaster. This Preferred List of Payers can be defined through the ManagePreferred Lists option of the User subsystem or by selecting Add toList(s), either Shared List or My List, when carrying out a findfunction for a payer.

[0712]FIG. 85 illustrates the General page of the Payer Details window.The General page includes fields specifying general informationregarding a payer.

[0713]FIG. 86 illustrates the Providers page of the Payer Detailswindow. A provider is any organization that supplies health care-relatedservices, such as a hospital, clinic, lab, and diagnostic center. On theProviders page in the Payer subsystem, the user can view the providersand caregivers for whom the Payer will cover patient expenses. The usermay pick either a provider or caregiver to show their identifiersassociated with the payer. These providers may be used for assigning IDsused in billing. (i.e., HMO provider ID). Management of payer-providersis carried out through the Providers page of the Payer Details window.

[0714]FIG. 87 illustrates the Service page of the Payer Details window.Claims and eligibility verification are examples of payer-relatedservices in the system. The system allows payers to interface with theseservices. Management of payer-services is carried out through theService page of the Payer Details window. For each Payer-servicedefinition, the user can link a payer with a service and indicate theinterface method used for the service.

[0715]FIG. 88 illustrates the Billing page of the Payer Details window.A lab identifies a payer by a billing ID. If the payer is to be billedfor a requisition, the payer's billing ID is sent to the lab with therequisition. The Billing page of the Payers subsystem lists thelab-defined billing i)s for the payer that the user selects. Managementof payer-billing identifiers is carried out through the Billing page ofthe Payer Details window.

[0716]FIG. 89 illustrates the Insurance Code page of the Payer Detailswindow. This page shows the insurance codes for a payer. An insurancecode is a user-defined identifier used to designate a payer. Each sitecan have more than one insurance code to designate the same payer.Management of payer-insurance codes is carried out through the InsuranceCode page of the Payer Details window.

[0717]FIG. 90 illustrates the Labs page of the Payer Details window. TheLabs page shows all the labs associated with the active payer. Theselabs are considered payer-approved labs. Payers can have contractualagreements with some labs wherein if the lab work for a patient is sentto a contracted lab, there is a financial benefit to be gained by thepayer. For each lab-payer set, each provider HDN Business can specifywhich lab in the set is their preferred one to use.

[0718] When creating a requisition, the user may choose what lab to sendthe order to. For patient and client billing, the lab may default to thedefault lab for the ordering provider HDN Business, although a user canchoose from any lab associated with the provider. For third partybilling, the payer is chosen first then the lab defaults to the payerpreferred lab if one exists, then to the HDN Business level default labif that lab is in the payer-lab list, or to nothing if neither of theseconditions apply. Again, the user can choose any of the labs setup forthe Provider HDN Business and override any default labs.

[0719] The association between labs and payers is managed through theLabs page of the Payer Details window. From this page, the user cancarry out the following tasks:

[0720] Associate existing labs with a payer

[0721] Designate a lab-payer combination as preferred

[0722] Remove existing associations between labs and payers

Admin: Manage Businesses: Providers

[0723] A provider is any organization that supplies health care-relatedservices, such as a hospital, clinic, lab, diagnostic center, etc. Usingthe Providers menu option of the Manage Businesses submenu, the user canmaintain information on the Providers in the user's network. In theProvider subsystem, the user can perform the following functions:

[0724] Create new provider records

[0725] View and/or modify existing provider records

[0726] Print provider records details

[0727] Delete provider records

[0728] Print lists of providers

[0729] In addition to basic demographic information, each providerrecord may include the following information: Information TypeDefinition Caregiver Caregivers associated with the provider Client IDsPhysicians' client IDs for particular labs Specialties Specialties ofthe provider

[0730]FIG. 91 illustrates the General page of the Provider Detailswindow. The General page includes fields specifying general informationregarding a provider.

[0731]FIG. 92 illustrates the Caregiver page of the Provider Detailswindow. A caregiver is a person who provides health care services topatients. Physicians, nurses, technicians, and physician's assistantsare all examples of caregivers. In the business of healthcare,caregivers are typically associated with providers. The management ofthis association is carried out through the Caregiver page of theProvider Details window. From this page, the user can carry out thefollowing tasks:

[0732] Associate existing caregivers with providers

[0733] View details of existing caregivers

[0734] Remove existing associations between caregivers and providers.

[0735]FIG. 93 illustrates the Specialties page of the Provider Detailswindow. A specialty defines a specific area of medicine, such ascardiology, pediatrics, or oncology, that a provider supplies. On theSpecialties page of the Providers subsystem, the user can viewspecialties associated with the selected Provider. Each specialty recordincludes a description, and the specialties are linked to caregivers.Management of provider specialties is carried out through theSpecialties page of the Provider Details window.

[0736]FIG. 94 illustrates the Client IDs page of the Provider Detailswindow. The caregivers listed in the Client IDs page are a subset ofthose listed in the Caregiver page. The list of caregivers on the ClientIDs page is based on the caregivers linked to the selected provider whohave been assigned Client IDs by a particular lab. Generally thesecaregivers are physicians, but any caregiver type can be assigned aClient ID.

[0737] A caregiver must have a client ID when he or she submits arequisition to a laboratory. If the caregiver does not have a client ID,he or she uses the default client ID, which is assigned to thecaregiver's HDN Business. The default client ID is typically used onlywhen the ordering caregiver does not have a client ID.

[0738] Management of provider client identifiers is carried out throughthe Client IDs page of the Provider Details window. The Client ID pagelists physicians, their client IDs, and the labs where they have IDsassigned.

Admin: Manage Security

[0739] Security administration involves setting up and maintainingsecurity aspects of the system. Using the Manage Security submenu of theAdmin menu, the user, i.e., an administrator, can control user access toconfidential patient information stored on the network. For example, thesecurity features may prevent a data record from being viewed ormodified by unauthorized users.

[0740] Security functions are accessed through the Manage Securitysubmenu of the Admin menu, as shown in FIG. 95. The Manage Security menuoption enables the user to manage key aspects of the system, such asshown in the following table: Key Aspect Description User AccountsInformation about the people associated with an HDN Business who accessthe system. HDN Businesses Businesses connected to the Health DataNetwork. Realms Collection of security roles and permission profiles.Permission Profiles General grants of access given by an owner to auser. Security Roles Groups of operations that are typically related toa specific function or position.

[0741] After the user make changes to the security system, the user mayupdate the users and realms through a Make Security Changes Effectivemenu option.

[0742] Security Checks—One important feature of the system is the secureexchange of information across a possibly very large and open network.To accomplish this, the system may check the following aspects of a useraccount before allowing the user to carry out a function: Securitychecks the... Which is a... Operation Task that a user carries out onthe data stored on the HDN. Operations may be global to the entire HDN.Security Role Collection of typically related operations. PermissionProfile Set of parameters for selected roles as they apply to users ofan HDN Business. Realm Collection of roles and permission profiles.

[0743] Roles and Permissions—In the preferred embodiment, the securitysystem is based on roles and permissions. These two concepts, combinedwith ownership, determine a user's authorization level, or theoperations the user can carry out. A role is a group of operations thatis typically related to a specific function or position. For example,various roles may be defined for physicians, nurses, office assistants,etc., or for any other function or position that a business desires.Roles limit transaction access to certain groups of users. For example,roles can be used to deny access to transactions related to clinicalresults except for people whose job requires that they have access. Onlypeople with an approved need to know should be assigned roles that havesearch and read capabilities on patient information. The system usersare classified and their permissions are assigned based on pre-definedsecurity roles.

[0744] A permission profile is created from a role. The permissionprofile specifies the role's clearance level, effective date, expirationdate, owner, and what realm it belongs to. A realm refers to acollection of roles and permission profiles. Usually the realm owns thepermission profile, but it can also be owned by a user.

Admin: Manage Security: User Accounts

[0745] Users are people associated with one or more HDN (Health DataNetwork) Businesses who access the system, such as caregivers,physicians, staff members, and administrators. The User Accounts menuoption of the Manage Security submenu may be used to manage informationregarding the HDN Businesses a user is linked to and the permissionsassigned to the user for a specific HDN Business.

[0746] Prior to adding users or modifying user information, anadministrator may initialize the security system by creating a realm,business entity, roles, permissions, etc. Users may then be added andassigned to HDN Businesses with specific permissions. The User Accountsmenu option enables access to the following information: Select thispage... To see... General User attributes and information used to verifythe user's identity HDN Business Status, active or inactive, of theselected user for the HDN Businesses listed Permissions Permissionprofiles for roles assigned to the user Site ID Healtheon Practice siteIDs assigned to the user

[0747]FIG. 96 illustrates the General page of the User Account Detailswindow. The General page includes fields specifying general informationregarding a user account.

[0748]FIG. 97 illustrates the HDN Business page of the User AccountDetails window. HDN Businesses are associated with a user by clickingAdd and then finding an HDN Business. The HDN Businesses page also showsthe status (active or inactive) of the selected user for the HDNBusinesses listed. To activate an inactive account, the user highlightsthe account and clicks Activate. To deactivate an active account,highlight the account and click Deactivate.

[0749]FIG. 98 illustrates the Permissions page of the User AccountDetails window. A permission is a general grant of access given by anowner to another user. A permission comprises an owner identifier, auser identifier, and a role identifier. Each permission may be mapped toa clearance level.

[0750] Permission profiles are assigned to users for a specific HDNBusiness. Users can have the same or different permission profiles withdifferent HDN Businesses. The Permissions page shows the permissionprofiles for roles assigned to the selected user.

[0751]FIG. 99 illustrates the Site ID page of the User Account Detailswindow. A Healtheon Practice site can be any health care entity, such asa caregiver, hospital department, or hospital. The site definitiondepends on the user's contractual agreement with Healtheon for using theHealtheon Practice system. The Site ID page contains a list of site IDsthat the user can assign to the selected user. The user then has accessto information at the specified Healtheon Practice site. The user set upthe site IDs using the Site ID subsystem of the Manage SystemIntegration option.

Admin: Manage Security: HDN Businesses

[0752] A Health Data Network (HDN) Business is any business connected tothe Health Data Network. An HDN Business may or may not share data withother HDN Businesses. Using the HDN Businesses menu option of the ManageSecurity submenu, the information regarding the HDN Businesses in theHealth Data Network may be managed. The HDN Business Details windowprovides access to the following information: Select this page... Tosee... General Specifics where the business fits in the network ContactEntity representatives Billing Reference and tax identification UsersAttributes and identity verification Configuration Network participation

[0753] When a new HDN Business is created, it may be linked it to aGlobal Location. This is referred to as assigning a data slice to an HDNBusiness. There is a field on the HDN Business General page called DataServer. By selecting one of the data servers on the list the user linkthe HDN Business to a Global Location.

[0754] The following table explains the fields on the General page ofthe HDN Business Details window, shown in FIG. 100: Field NameDefinition Data Server The data server where the data for the HDNBusiness is stored. HDN Business Link The business that is linked tothis HDN Business. The type of business is determined by the value inthe HDN Business Type field. On windows and printouts that include anaddress, such as a Requisition, the address from the linked business isused. HDN Business Name The name of the HDN Business. HDN Business TypeThe type of HDN Business. The value in this field determines whichbusiness can be selected in the HDN Business Link field. Parent HDNBusiness The parent HDN Business for the HDN Business. Realm The realmthe HDN Business belongs to.

[0755] Other HDN Business pages include a Contact page, a Billing page,and a Users page.

Admin: Manage Security: Realms

[0756] A realm is a collection of roles and permission profiles. Auser's access to the system is determined by roles and permissions. Thepurpose of a realm is to specify the roles and permission profilesassociated with an HDN Business. Each realm may include one or more HDNBusinesses that use the same set of roles and permission profiles.Although a realm can include several HDN Businesses, an HDN Business canbe linked to only one realm. Multiple realms may exist, one of which maybe the hub realm.

[0757] Through the Realms menu option of the Manage Security submenu,the user can maintain the list of HDN Businesses in a realm. Inaddition, the user can define the roles and permissions for the realm.The Realm menu option enables access to the following information:Select this page . . . To see . . . General Realm name and descriptionHDN Businesses HDN Businesses in the realm Permission ProfilesPermission profiles associated with the realm Roles Roles associatedwith the realm Users Online Users currently online who have rolesassociated with a realm

[0758]FIG. 101 illustrates the General page of the Realm Details window.The General page includes fields for entering a name and description fora realm.

[0759]FIG. 102 illustrates the HDN Businesses page of the Realm Detailswindow. The HDN Businesses page lists the HDN Businesses linked to theselected realm. If the HDN Business is a sub-business of another, theparent business entity is also listed. From this window, the user cancarry out the following tasks:

[0760] Create New HDN Businesses that are automatically associated withthe active realm

[0761] Get Details of an existing HDN Business the is associated withthe active realm

[0762]FIG. 103 illustrates the Permission Profiles page of the RealmDetails window. The Permission Profiles lists the permission profilesassociated with a realm. From this window, the user can carry out thefollowing tasks:

[0763] Create New permission profiles that are automatically associatedwith the active realm

[0764] Get Details of an existing permission profile the is associatedwith the active realm

[0765]FIG. 104 illustrates the Roles page of the Realm Details window.The Roles page lists the roles associated with a realm. From thiswindow, the user can carry out the following tasks:

[0766] Create New security roles that are automatically associated withthe active realm

[0767] Get Details of an existing security roles the is associated withthe active realm

[0768] The Users Online page of the Realms Details window lists theusers currently online who have roles associated with the specifiedrealm.

Admin: Manage Security: Permission Profiles

[0769] A permission is a general grant of access given by an owner to auser. Usually the realm owns the permission profile, but a user can alsobe an owner. In one embodiment, a permission comprises a role, an owner,a clearance level, an effective date, and an expiration date. Thus, whena permission profile is assigned to a user, information may bespecified, such as the operation the user can perform, the level ofclearance entailed, and a beginning and ending date between which theoperations can be performed.

[0770] Through the Permission Profiles menu option of the ManageSecurity submenu, the user, e.g., an administrator, can createpermission profiles. The user can then assign the permission profiles toselected users. FIG. 105 illustrates the Permission Profile Detailswindow, which can be used to create or edit permission profiles. Thefollowing table describes the fields found on the Permission ProfileDetails window: Field Name Description Assigned Users The users thatthis permission profile has been assigned to. Effective Date The datethe permission profile becomes effective. Expiration Date The date thepermission profile expires. Maximum Clearance The maximum clearance thatcan be assigned to users for this permission profile. Owner Type Thetype of owner for the permission profile. Owner Name The owner of thepermission profile. Realm Name The realm for which the permissionprofile is created. Role Name The role for which the permission profileis defined.

[0771] There are preferably no limitations on the number of permissionprofiles that can be assigned to users. In one embodiment, permissionprofiles are limited to one role each, and more than one permissionprofile may be assigned to a user who has several roles. Also, the samepermission profile may be assigned to different users who perform thesame role. For example, three different hospital registration clerkscould share the same role that allows them to view and modify patientinformation.

[0772] The following procedure may be used to assign a permission to auser:

[0773] 1. On the Permission Profile Details window, the user clicksAssign. In response, the first window of the Assign Permission wizardappears.

[0774] 2. The user then selects a Clearance level from the drop-downlist for the field and clicks Next. The second window of the AssignPermission wizard appears.

[0775] 3. The user enters the Effective Date and Expiration Date for thepermission assignment and clicks Next. The third window of the AssignPermission wizard appears.

[0776] 4. From the list of users, the user selects one or more users toassign the permission profile to.

[0777] 5. The user clicks Finish. The system validates the assignment.If the assignment was successful, the Permission Granted dialog boxappears. If the assignment was not successful, the Permission NOTGranted dialog box appears.

Admin: Manage Security: Security Roles

[0778] As described above, a role comprises a group of operations thatis typically related to a specific function or position. Roles limittransaction access to certain groups of users. For example, roles can beused to deny access to transactions related to clinical results exceptfor people whose job requires that they have access to this information.Only people with an approved need to know should be assigned roles thathave search and read capabilities on patient information.

[0779] When the user creates a role in the Security Roles subsystem, theuser names the role and specifies its realm. The user then selects froma list of available user accounts that are linked to one or moreoperations. The user can add and remove the user accounts that areassociated with the role. The user maintains existing security rolessimilarly.

[0780] Defined roles may be available for permission assignment by anyand all realms in the network. Roles defined locally by a realm may beavailable for permission assignment on that realm only.

[0781]FIG. 106 illustrates the Security Role Management window. Fromthis window the user can:

[0782] filter the Security Role Management list

[0783] print the Security Role Management list

[0784] create a new security role

[0785] display details of an existing security role

[0786] create a permission profile for the highlighted security role

[0787] update the security roles

[0788]FIG. 107 illustrates the Security Role Details window forspecifying or viewing details of a particular role. A security rolecomprises objects and the operations that can be carried out on thoseobjects. The Security Role Details window has two panels, each with twolists. The top list in the left-hand panel displays all availableobjects. When the user clicks on an object, the list of operations thatcan be carried out on those objects appears in the list at the bottom ofthe panel. The top list in the right-hand panel displays all objectswhich have been assigned to the security role. When the user clicks onan object, the list of operations which can be carried out on thatobject that have been assigned to the security role appears on the listat the bottom of the panel.

[0789] To assign object-operations to a security role, the user clickson an object in the Available panel and then selects the desiredoperations that users with this role should be able to carry out on thatobject. Clicking Add assigns the object-operations to the security role.

Admin: Manage Security: Make Security Changes Effective

[0790] Using the Make Security Changes Effective menu option of theManage Security submenu, the user updates users and realms with changesthat have been made to the security system, such as creating a new useror changing a user password. If this function is not performed, then thenext time a user logs on to the system, the changes may occur anyway.

Admin: Manage Health Care Codes

[0791] Various sets of health care codes may be used throughout thesystem, as shown in the following list.

[0792] CPT-4 codes

[0793] ICD-9 codes

[0794] Specialties

[0795] Analyte codes

[0796] Profile codes

[0797] Report codes

[0798] Test codes

[0799] Code sets are accessed through the Manage Health Care Codes menuoption of the Admin menu.

[0800] Analyte Codes—An analyte is the smallest unit or component forwhich a laboratory test is performed. A laboratory test may includemultiple analytes. For example, a CBC (complete blood count) is a singletest that includes multiple analytes. Analyte codes may be specific to alab, and may be pre-loaded into the system. As updates become available,these may also be loaded into the system automatically, with no actionrequired on the part of the user. Using the Analyte Codes function, theuser can find and print codes. Analyte codes are used for viewing andreporting on results.

[0801] CPT-4 Codes—Current Procedural Terminology version 4 (CPT-4)codes can be used by physicians to report the services that they provideto their patients. These codes are used for evaluation and management.Because CPT-4 codes have been universally adopted in the healthcareindustry, they are not specific to any one lab. These codes may bepre-loaded into the system. As updates become available, these may alsobe loaded into the system automatically, with no action required on thepart of the user. Using the CPT-4 Codes function, the user can findcodes and print lists of codes.

[0802] Because the number of CPT-4 codes stored on the system may bevery large, the user can create a list of preferred codes, i.e., thosecodes that the user frequently uses. This makes locating a CPT-4 codemuch easier and faster. When the user selects Preferred from the CPT-4Code field control menu, the Preferred List of CPT-4 Codes appears withthe user's list and the shared list combined. This allows the user tosee the list of preferred CPT-4 codes for the entire HDN Business, aswell as those that the user have added for the user's own use. Even ifthe user is a new user, the user still has a Preferred List of CPT-4Codes that includes codes from the shared list.

[0803] ICD-9 Codes—International Classification of Diseases version 9codes (ICD-9 coding) are used in clinical settings for reportingdiagnoses and diseases to U.S. Public Health Service and Health CareFinancing Administration programs. Because ICD-9 codes have beenuniversally adopted in the healthcare industry, they are not specific toany one lab. These codes may be pre-loaded into the user's system. Asupdates become available, these may also be loaded into the systemautomatically, with no action required on the part of the user. ICD-9diagnosis codes are used by functions accessed via the Orders subsystem,which includes utilities for preparing and submitting requisitions.

[0804] Using the ICD-9 Codes function, the user can find codes and printlists of codes. To simplify locating codes, the system differentiatesbetween diagnosis and procedure codes. The list of ICD-9 codes on whichto search is determined by the requirements of the field or list fromwhich the search was initiated. Because the number of ICD-9 codes storedon the user's system may be very large, the user can create lists ofpreferred diagnosis and procedure codes, i.e., those codes that the userfrequently uses. This makes locating an ICD-9 code much easier andfaster.

[0805] Profile codes—Profile codes are used for both requisitions andfor results. In requisitions, a lab profile includes multiple individualtests, which can be ordered collectively as a profile or individually asneeded. In results, a lab profile includes multiple report codes and mayinclude a panel, i.e., multiple tests that have the same report code.Profile codes may be specific to a lab, and may be pre-loaded into thesystem. As updates become available, these may also loaded into thesystem automatically, with no action required on the part of the user.Using the Profile Codes function, the user can find codes and printlists of codes. Profile codes are used by both functions accessed fromthe Orders menu and functions accessed from the Results menu.

[0806] Report Codes—A report code identifies the results of a laboratoryclinical test. It differs from an order code in that an order code isthe test code used to send an order, and a report code is the code usedto return results. A collective set of multiple report codes is referredto as a lab profile. Report codes may be specific to a lab, and may bepre-loaded into the system. As updates become available, these may alsoloaded into the system automatically, with no action required on thepart of the user. Using the Report Codes function, the user can findcodes and print lists of codes. Report codes are used by the functionsaccessed via the Results menu for viewing and reporting on results.

[0807] Specialty List—Specialties define the specific area of medicineor focused approach to health care that a provider or caregiversupplies. Using the Specialty List function, the user may create thespecialties that are used throughout the system. Once created, thesespecialties can then be linked to provider and caregiver records.

[0808] Test Codes—A test code is used to specify what tests need to beperformed. Test codes may be specific to a lab and may be loaded intothe system based on the transmission mode configuration of the lab. Ifthe lab accepts requisitions electronically, the test codes may bepre-loaded into the system. As updates become available, these may alsoloaded into the system automatically, with no action required on thepart of the user. If the lab only accepts requisitions manually, thetest codes can be pre-loaded into the system and/or added through theuser interface. Using the Test Codes function, the user can carry outthe following functions regardless of the transmission modeconfiguration for the lab: Finding codes; and Printing lists of codes.Because the number of test codes stored on the system may be very large,the user can create a list of preferred codes, i.e., those codes thatthe user frequently uses. This makes locating a test code much easierand faster.

Admin: Manage Resources

[0809] As used herein, resources refer to the manpower, money,facilities, equipment, and supplies used to deliver healthccareservices. Using the Manage Resources submenu of the Admin menu, the usercan add, remove, and modify these resources as appropriate.

Admin: Manage Resources: Caregivers

[0810] A caregiver is a person who provides health care services to apatient. For example, physicians, nurses, technicians, and physician'sassistants are all caregivers. Using the Caregiver menu option of theManage Resources submenu, the user can view the caregivers associatedwith the HDN Business the user is logged on to. The user can search fora caregiver by identifier or the user can perform a general search. Theuser can also maintain information regarding the caregivers the userdoes business with. This includes:

[0811] Creating new caregivers

[0812] Maintaining information on existing caregivers

[0813] Deleting existing caregivers

[0814] Printing lists of caregivers

Admin: Manage System Integration

[0815] System Integration refers to a group of settings that affectcertain aspects of the system. These settings fall within four maincategories that the user can manage using the corresponding menu optionsin the Manage System Integration submenu: System Aspect Menu OptionsCode Sets Local Codes Global Codes Code Translations System IdentifiersHDN Business-Specific Identifier Types Site IDs Document StorageDocument Routing Configuration Documentation Distribution Lists NetworkConfiguration Network Configuration

[0816] From the Manage System Integration submenu, the user can defineand maintain the codes, identifiers, and rules related to these fourareas.

Code Sets

[0817] The user may define and maintain the user's own code sets, suchas groups of values or symbols used to represent information such as apatient's employment status, religion, marital status, etc. These valuesusually appear in drop-down lists from which the user makes a selection.To handle the code sets, the system may be operable to map and translateglobal and local codes. Global codes refer to user-defined codes thatare used uniformly across the entire network (hub). Local codes refer touser-defined codes that are specific to a certain HDN Business.

Code Translation

[0818] The Code Translation function provides a mechanism fortranslating codes between different HDN Businesses. Using the CodeTranslation function, the user can map system codes to HDN Businesscodes. The purpose of code translations is to support networkparticipants having different sets of valid values for the same fieldand to provide a mapping from one participant's representation to thatof another participant's representation.

[0819] For example, suppose that two hospitals, A and B, areparticipants in the same network. Hospital A has three Patient Typecodes: IN for inpatient, OU for outpatient, and OT for other. Hospital Bhas four Patient Type codes: I for inpatient, O for outpatient, E foremergency, and B for Obstetrics. Through the Code Translation function,both participants can maintain their existing coding systems. The systemautomatically translates and converts codes when data is shared betweenparticipants. Code translation lets a participant receive data fromanother participant and view that data in their own native domain setusing their own coding systems, regardless of who owns the data.

[0820] The idea behind code translations is to provide for each codetype, such as relationship code type and religion code type, a set of:

[0821] The system codes

[0822] HDN Business codes (if a network participant wants their own set)

[0823] Mappings for inbound and outbound translation

[0824] The Code Translations menu option provides access to thefollowing information: Select this page . . . To see . . . GeneralInbound and outbound translations for the code type that the user selectThe system Codes Set of The system codes for the code type that the userselect HDN Business Codes Set of HDN Business codes for the code typethat the user select

[0825] The General page of the Code Translations subsystem lists inboundand outbound code translations. Inbound and outbound translations differbased on whether the code is being translated from a system source orHDN Business source. The following table describes these two types ofcode translation: Code Translation Definition Inbound Mappings from HDNBusiness codes to system codes

[0826] Each system code may map to exactly one code in each defined HDNBusiness code set. This makes outbound translation possible. Each HDNBusiness code may be mapped to exactly one system code value. This makesinbound translation possible. The system set of codes within a code setmay include a superset of all possible code descriptions that might beused by any HDN Business set in the network.

[0827] The System Codes page of the Code Translations subsystem liststhe set of system codes for the code type that the user selects, such asMS for marital status. The system codes then appear in the Outboundsection on the General page. For example, the system marital statuscodes appear on the System Codes page after the user selects MS as thecode type. If the user clicks the General page button to see the Generalpage, the system marital status code set appears in the Outbound sectionof the General page.

[0828] The HDN Business Codes page of the Code Translations subsystemlists the set of HDN Business codes for the code type that the userselect, such as MS for marital status. The HDN Business codes thenappear in the Inbound section on the General page. For example, thesystem marital status codes appear on the HDN Business page after theuser selects MS as the code type. If the user clicks the General pagebutton to see the General page, the HDN Business-specific marital statuscode set appears in the Inbound section of the General page.

System Identifiers

[0829] A system identifier is a string of characters used as a label,such as BAN for Billing Account Number. There are two categories ofsystem identifiers: Caregiver and Patient. The Registration flag is usedby the identifier labels Insurance Code and Patient Account. Each HDNBusiness may define one registration label for each type (Caregiver,Patient or Payer). For example the registration label for Payer type maybe Insurance Code and the registration label for Patient Type may bePatient Account. Because identifiers are categorized, only the patientidentifiers appear in the Patient subsystem. These categories are usedto store IDs originating from external systems such as PracticeManagement Systems. These identifiers help distinguish between thevarious types of account numbers. Identifiers might also be used todistinguish between types of payer account numbers or types of caregivercertificate numbers.

Document Storage

[0830] Medical personnel and related administrative staff receive manyreports and other documents in paper form. Often, these are generatedelectronically by various systems, then printed and distributed by amanual delivery method. In the preferred embodiment, the system allowsits participants to automatically receive electronic images of printeddocuments that would otherwise have to be received through interofficemail, fax, US Mail, or some other physical delivery method. The DocumentRouting Configuration subsystem allows the user to manage and configurethe receipt and distribution of documents.

[0831] Routing and Distribution—Routing allows the user to map adocument recipient to a user. A document's routing specifies its firstpoint of entry into the system. Distribution defines which users shouldreceive the document in addition to the first recipient. For example, adocument, such as a patient's insurance statement, might be addressed toa physician, but the document should also go to the claims administratorworking in his or her practice. Thus, the document should be routed tothe claims administrator. The claims administrator might need todistribute or forward the insurance statement to several clerks. Thus,the document should be routed to the specific clerks.

Document Routing

[0832] Routing allows the user to specify a recipient for a document. Arouting configuration is the “path” the user wants a document to takefrom its source to a destination. Through the Document RoutingConfiguration menu option of the Manage System Integration submenu, theuser sets up the rules that determine how and to whom documents arerouted. Documents routed by these rules may then be accessed through theView Documents menu option of the User menu. The user can select theDocument Routing Configuration menu option to access the followinginformation: Select this page . . . To see . . . Routing Rules forrouting the user's documents Sources Client sources from which the userreceives documents Types Type of documents that the user receive

[0833] Using the Routing page, the user creates the rules for routingthe user's documents. The user can set up two types of routing rules:General Routing Rules and Document-Specific Routing Rules.

[0834] General routing rules are for documents from a specific sourcethat are to be sent to a single person. For example, if all incomingelectronic clinical results documents from an SBCL lab in St. Louis areto be sent to a lab tech in the user's office regardless of to whom theresults are addressed, the user can set up a rule that automaticallyroutes documents of that category from the specific source to thatperson. This is a general routing rule. The user creates general routingrules for a source by selecting a pre-defined category of documents,entering an addressee, and then selecting a user to whom electronicdocuments of the selected category that are addressed to the addresseeare routed.

[0835] Document-specific routing rules are for specific types ofdocuments that are to be sent to a single person. For example, if allincoming electronic radiology documents are to be sent to theradiologist in the user's office regardless of to whom the results areaddressed, the user can set up a rule that automatically routesdocuments of that type to that person. This is a document-specificrouting rule. The user creates document-specific routing rules for asource by selecting a document type, entering an addressee, and thenselecting a user to whom electronic documents of the selected type thatare addressed to the addressee are routed.

[0836] When the user sets up document routing rules, the user firstspecifies the source of the document. The Sources page is used to definethese sources. The Sources page lists the name and description of eachsource.

[0837] When the user creates document-specific routing rules, the userselects a document type. The Types page is used to define documenttypes. Each document type falls in a system-defined category. Thefollowing table lists common document types and their categories:Category Document Type Administrative Patient history Patientdemographics Clinical Radiology Diagnosis Patient Evaluation FinancialPayments From Patient Billing

Document Distribution Lists

[0838] A document distribution is like a document routing in that ituses rules to automatically distribute electronic documents that havebeen routed to a specific user. Documents distributed by these rules arethen accessed through the View Documents function of the User menu.However, unlike a routing, which only allows the user to automaticallysend a document to a single user, document distribution allows the userto create a list of users to whom a single document is sent.

[0839] The Document Distribution Lists function allows the user tocreate general distribution rules for a “routed to user” by selecting asystem-defined category of documents and then selecting users to whomelectronic documents of the selected category are distributed. The usercan also create document-specific distribution rules for a “routed touser” by selecting a document type and then selecting users to whomelectronic documents of the selected type are distributed.

[0840] Although the embodiments above have been described inconsiderable detail, numerous variations and modifications will becomeapparent to those skilled in the art once the above disclosure is fullyappreciated. It is intended that the following claims be interpreted toembrace all such variations and modifications.

We claim:
 1. A method for maintaining a Global Master Patient Index(GMPI), the method comprising: receiving information specifying changesto a patient record; performing a search through one or more databasesfor one or more matching records that match the patient record, inresponse to the received information; and if one or more matchingrecords are found, creating an unconfirmed link between the patientrecord and each matching record.
 2. The method of claim 1, wherein theinformation specifying changes to a patient record is informationspecifying a new patient record; wherein said performing a searchthrough one or more databases comprises performing a search for one ormore records that match the new patient record.
 3. The method of claim1, wherein said performing the search through one or more databases forone or more matching records that match the patient record is based onreal world primary key information.
 4. The method of claim 1, furthercomprising: performing a search for a patient record in response to userinput search criteria; displaying a list of records that match thesearch criteria, wherein the list includes a set of two or more recordsthat have unconfirmed links between the records; receiving user inputselecting one of the records from the set; receiving user inputspecifying confirmation information for the unconfirmed links.
 5. Themethod of claim 4, wherein in response to the confirmation informationfor an unconfirmed link the link is either: 1) confirmed or 2)denigrated.
 6. The method of claim 5, further comprising: receiving userinput changing a confirmed link to a certified link.